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such  a  model.  The  feasibility  of  such  a  model  was  established.  It  will 
include  the  six  key  resource  types  required  to  support  avionics  software 
personnel,  support  hardware,  support  software,  facilities  (buildings), 
program  documentation  and  flight  test  aircraft/ranges.  Some  preliminary 
estimating  relationships  were  identified.  A  detailed  roadmap  for  develop¬ 
ing  the  model  was  generated.  Phase  II  of  the  PSCM  program  will  provide 
AFWAL/AA  with  an  operating  model  for  predicting  avionics  embedded  software 
support  costs. 


PREFACE 


The  Predictive  Software  Cost  Model  Study  Phase  I  Technical  Report  is 
prepared  in  two  separately  bound  volumes. 

Volume  I  -  Final  Technical  Report 

Volume  II  -  Software  Package  Detailed  Data 

The  Air  Force  Program  Monitor  was  Mr.  Daniel  V.  Ferens,  Systems  Evaluation 
Group,  Avionics  Systems  Engineering  Branch  (AFWAL/AAAA-3) . 
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I.  GENERAL 


This  volume  contains  the  Predictive  Software  Cost  Model  Study  Data 
Collection  forms  prepared  from  data  collected  during  visits  to  Air  Logistics 
Centers.  Visits  were  made  to  all  five  ALCs  (Oklahoma  City,  Sacramento, 

Warner -Rob ins ,  Ogden,  and  San  Antonio)  to(l  )  identify  digital  avionics 
software  packages  now  or  soon-to-be  maintained  by  the  Air  Force,  (2)  determine 
current  and  proposed  software  support  policies  and  procedures,  (3)  describe 
key  characteristics  of  Air  Force  avionics  software  support  agencies,  (4) 
collect  data  on  a  sample  of  six  avionics  software  packages,  (5)  collect  data 
on  electronic  warface  software  support  at  WRALC,  (6)  collect  data  on  automatic 
test  equipment  software  support  at  SAALC,  and  (?)  identify  possible  sources 
of  historical  data  for  a  follow-on  model  development  effort. 

The  Data  Collection  Forms  contain  the  following  information  for  each 
software  package  considered  in  the  study: 


General  Software  Package  Description 

Maintenance  Agency  Personnel 

Maintenance  Agency  Work  Distribution 

Maintenance  Agency  Cost  Accounting  System 

Maintenance  Agency  Policies  and  Procedures 

Personnel  Description 

Facilities  -  Buildings 

Facilities  -  Computers 

Support  Software 

Training  Requirements 

Flight  Test  Requirements 

Maintenance  History 

Maintenance  Cost  History 

Historical  Data  Sources 

Software  Support  Cost  Predicting  Recommendations 

The  Data  Collection  Forms  and  associated  supportive  data  are  presented 
in  Appendixes  A  through  H. 
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PREDICTIVE  SOFTWARE  COST  MODEL 
FIELD  EVALUATION  REPORT 

GENERAL  SOFTWARE  PACKAGE  DESCRIPTION _ DATE:  27  July  1979 

ALC:  OC/NWC  WEAPON  SYSTEM:  A-7D 

SOFTWARE  PACKAGE:  Operational  Flight  Program 
PERSONNEL  CONTACTED: 

Dave  Corder,  MMEC  (405)  734-2453 
George  Wann,  MMEC 

Mark  Jacobson  (China  Lake),  MMECZA  (714)  939-5575/5474 

SOFTWARE  PACKAGE  CHARACTERISTICS: 

SIZE:  15K 

LANGUAGE:  Assembly 

application:  Navigation /Weapons  Delivery 
COMPLEXITY:  Average 
YEAR  DEVELOPED:  1968 
DEVELOPER:  IBM/Vought 

comments  See  p.  A-2  for  a  rating  of  quality  attributes. 

HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS: 

MANUFACTURER:  IBM 

MODEL  NUMBER/DESIGNATOR:  TC-2 
WORD  SIZE:  16  bit 

MEMORY  SIZE.  16K 

memory  fill:  89%  (1860  spare  16-bit  words) 


WEAPON  SYSTEM  USE: 

NUMBER  OF  USERS:  370  aircraft,  1,000  pilots 
LOCATIONS  OF  USERS:  See  page  A-3 . 
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CONTINUATION  SHEET  -  Software  Package  Characteristics 


DATE:  27  July  1979 


Rate  the  Package  on  the  following  Quality  attributes:  (l=Poor;  10=Excellent) 


Accessibility:  3 

Accountability:  6 

(Timing  &  Testing  Handloads) 

Access  Audit:  3 
(Cross  references  only) 

Access  Control:  7 
Accuracy:  8  (some  algorithms 
are  noisy) 

Augmentability :  5  (I/O,  Core 

and  Time  Bound) 

Clarity:  3  (Program  Structure 

is  not  good) 

Communicativeness:  10 
Communications,  Commonality:  8 
(Mostly  machine  dependent) 
Completeness:  8 

(Most  of  the  program  is  stable) 
Conciseness:  8 

Consistency: 

Internal  Consistency:  8 
External  Consistency:  3 

Correctness:  10 

Data  Commonality:  10  (Checked 
at  assemble  time) 

Efficiency : 

(An  area  of  major  concern) 
Execution  Efficiency:  10 
Storage  Efficiency:  10 

Error  Tolerance:  7  (Back-up  modes 
are  adequate;  some  hard  failures) 
Expandability:  3  (Timing 

constraints  cause  difficulty) 
Generality:  10 


Instrumentation:  7  (Hardware  Instrumentation)) 
(output  &  S/W  data  reduction,  SOVAC) 
Interoperability:  6  (Difficult  because  of 
analog  interfaces) 

Integrity:  Not  applicable 
Legibility:  3  (Assembly  Language) 

Maintainability:  3 

Modifiability:  3 

Modularity:  3 

Operability:  7 

Performance:  3  (system  design  is  old) 

Portability:  5  (can  be  run  on  upgraded 
TC-2A) 

Reliability:  10  (User  does  not  complain) 

Robustness:  5  (There  is  some  quality 
checking) 

Reusability:  3  (Minimal  due  to  poor  structure)! 
Selfcontainedness :  10  (No  complaints) 

Selfdescriptiveness :  5 

Simplicity:  3 

Structuredness:  3  | 

Testability:  5  (Test  facilities  & 

procedures  are  good,  but 
program  is  hard  to  test) 


Human  Engineering  5  (Moding  &  Traceability:  5  (Built-in  modification 

operator  functions  bound  by  hardware)  procedures) 

Independence:  Training:  5  (Difficult  because  S/W  is 

complex) 

Device:  3  (TC-2  only)  Understandability :  5  (Some  bad  areas) 

Software  System:  (TC-2  only  no 

operating  system)  Usability  (as-is  utility):  7  (The  OFP  is 

the  core  of  a  very  successful  weapons  system) 
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PREDICTIVE  SOFTWARE  COST  MODEL 

MAINTENANCE  AGENCY  PERSONNEL _ DATE:  2 


ALC:  OC/NWC  OFFICE  SYMBOL:  OCALC/MMECZA 


KEY  PERSQNNEL/OGRANIZATION: 

Engineering  Division 
MME 


Computer 

Resources 

Branch 

MMEC 

Dave  Corder 


Operations 
and  Support 
Branch 
MMED 


China  Lake 
Organization 
MMECZA 

Mark  Jacobson 


Technical 
Order  Section 
MMEDU* 

J.  A.  Wagoner 


*In  charge  of  AFCR/CPIN  System 


[  TOTAL  ASSIGNED  PERSONNEL  (NUMBER  &  TYPE!:  To  MMECZA 
6  Civil  Service 

Additionally,  about  8  manyear  of  effort  is  procured  from  NWC  annually. 


TOTAL  PACKAGES  MAINTAINED  (NUMBER  &  TYPE): 

1  A7-D  Operational  Flight  Program 
1  A7-D  Operational  Test  Program 
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PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  WORK  DISTRIBUTION 


DATE:  27  July  1979 


DESCRIPTION  OF  WORK  PACKAGE  DISTRIBUTION.  INCLUDING  RESPONSIBILITIES  AND  DEGREE  OF 
SPECIALIZATION  OF  AF/CS/CONTR  PERSONNEL 

There  is  minimal  maintenance  on  the  Operational  Test  Program.  Responsibilities  on 
the  Operational  Flight  Program  are  distributed  as  follows: 


Position  (Civil  Service) 


Functions 


Supervisory  Electronic  Engineer 


Mathematician 


50%  managerial,  50%  technical  (program 
design  on  flight  computer) 

50/50  simulation  and  data  reduction 


Computer  Scientist 


Simulation  -  35% 

Data  reduction  -  35% 
Programming  tests  -  15% 

TC-2  support  software  -  15% 


Equipment  Specialist  (Avionics) 


Integration  testing  -  set  up 
instrumentation  on  flight  test  aircraft 


Computer  Operator 


Run  validation  and  verification  tests 


Additionally,  eight  manyears  of  assistance  is  procured  from  the  Navy.  This  is 
detailed  on  page  A-6. 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET:  Work  Distribution 


DATE:  27  July  1979 


Navy  Personnel: 
uantity  (manyears) 


Function 


Program  Management 

Administrative  Assistance 

Upgrading  of  equipment  and 
facilities,  support  software 
development 

Technical  analysis  of 
algorithms,  etc.  (e.g., 
weapons  ballistics) 

Data  reduction 

Flight  test  support  - 
target  preparation,  weapons 
impact  siting,  data 
collection,  etc. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  COST  ACCOUNTING  SYSTEM _ DATE:  27  July  1979 


Costs  are  collected  at  a  high  level  of  aggregation. 

Payments  to  Naval  Weapons  Center  for  services  are  categorized  as  follows: 

I.  MANAGEMENT  ENGINEERING 

a)  Administration  and  Budget 

b)  Materials  and  Supplies 

c)  Travel 

d)  Contracted  Documentation 

e)  Contracted  Configuration  Management 

f)  NWC  Engineering  Labor 

II.  SIMULATION  AND  LABORATORY  FACILITIES 

a)  Labor 

b)  Contracted  Maintenance 

c)  Equipment  via  NWC 

d)  Computer  Use  Charges 

III.  FLIGHT  TESTING 

a)  Range  Charges 

b)  Data  Reduction 

c)  A/C  Modification/Instrumentation 

Manhours  by  the  assigned  Air  Force  civil  service  personnel  are  not  documented  by  a 
task  or  function  breakdown. 
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MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES _ DATE:  27  July 

SUPPORT  PHILOSOPHY: 

The  A-7D  software  support  philosophy  is  based  on  the  need  for  a  highly  responsive 
and  continuing  engineering  capability  for  analysis  and  correction  of  deficiencies 
reported  and  for  design  and  production  of  major  changes  determined  necessary  and 
approved  for  implementation.  The  co-location  of  the  Air  Force  Engineering 
Support  Team  at  the  Navy  facility  has  provided  for  an  interchange  of  experience 
and  information  and  has  resulted  in  a  cost  savings  to  the  Air  Force  by  sharing 
an  existing  DoD  facility. 

The  Air  Force-Navy  Interservice  Support  Agreement  (ISA)  is  being  continued  for 
the  A-7D  OFP/OTP  support  at  China  Lake  to  permit  a  dynamic  organic  engineering 
function  for  analysis  and  correction  of  deficiencies  reported  and  for  the  design 
and  production  of  all  OFP  changes  determined  necessary  and  approved  for  imple¬ 
mentation  by  the  A-7D  Computer  Program  Configuration  Sub-Board  and  OC-ALC  and 
AFLC  Configuration  Control  Boards.  This  includes  OFP  changes  associated  with 
both  software  deficiencies  and  hardware  modifications.  The  Engineering  Support 
Team  also  provides  an  integrated  weapons  system  avionics  testing  capability  for 
enhancement  studies  and  direct  support  to  the  using  commands  and  to  the  item 
_ Managers  of  A-7D  subsystems  and  equipment.  (Continued  on  p.  A-9) _ 

CHANGE  CONTROL  METHODS: 

FORMAL  OR  INFORMAL:  Formal 


CHANGE  REVIEW  PROCESS:  1116  change  review  process  is  diagrammed  on  p.  A-22,. 


CONFIGURATION  IDENTIFICATION  METHODS:  OFP  title  is  updated  by  assembler. 

CONFIGURATION  CHANGE  CONTROL  METHODS:  Change  control/status  accounting 
methods  are  described  on  p.  A-23. 

CONFIGURATION  STATUS  ACCOUNTING  METHODS: 

See  page  A-23. 

SOFTWARE  LIBRARY  CONTROL  PROCEDURES:  The  DEC  library  is  used. 
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CONTINUATION  SHEET  -  Support  Philosophy 


DATE:  27  July  1979 


This  support  philosophy  is  expanded  in  the  Memorandum  of  understanding 
reproduced  on  pp.  A-10  through  A-15,  and  the  A-7D  Operations/Flight  Program 
Support  Plan  74-1A  reproduced  on  pp.  A-16  through  A-21. 
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CONTINUATION  SHEET 


DATE:  27  July  1979 


MEMORANDUM  OF  UNDERSTANDING 
FOR  A-7D  AIRCRAFT  COMPUTER  PROGRAMS 
BETWEEN  AIR  FORCE  AND  NAVY 


1.  BACKGROUND 

1.1  The  A-7  Aircraft  is  a  joint  service  weapon  system  using  an  airborne 
digital  computer  to  integrate  the  Big  "8"  avionics  navigation  and  weapons 
delivery  system.  Operational  flight  program  (OFP)  tapes  are  used  within  the 
computer  memory  and  will  require  maintenance  (reprogramming,  updating,  vali¬ 
dation)  throughout  the  life  of  the  A-7  aircraft  system.  The  Navy  developed 
an  organic  capability  at  the  Naval  Weapons  Center  (NWC)  China  Lake  to  perform 
maintenance  for  the  A-7C/E  aircraft.  An  A-7D  OFP  Engineering  support  team 
was  formed  in  1974  and  located  at  the  Naval  Weapons  Center,  China  Lake,  CA, 
to  co-share  the  Naval  facility  and  maintain  the  A-7D  OFP.  This  team  consists 
of  nine  OC-ALC/MME  personnel  and  three  TAC  personnel.  In  addition,  the  Air 
Force  funds  NWC  for  rhe  Navy  efforts  required  on  A-7D  tapes  as  a  pro  rata 
share  of  those  jointly  used  facilities.  These  actions  result  in  a  cost  savings 
to  the  Air  Force  and  Navy  by  utilizing  an  existing  DOD  facility/capabili ty , 
provide  for  an  interchange  of  experience,  information,  and  maintain  a  basic 
nucleus  of  trained  Air  Force  personnel  in  the  airborne  computer  programming 
field. 

2.  PURPOSE 

2.1  The  purpose  of  this  Memorandum  of  Understanding  is  to  provide  for  the 
extension  of  the  Air  Force-Navy  Interservice  Agreement  dated  October  1973  in 
accordance  with  the  terms  and  conditions  stated  herein.  In  those  instances 
where  this  Memorandum  of  Understanding  conflicts  with  the  Air  Force-Navy 
Interservice  Agreement  dated  October  1973,  the  contents  of  this  Memorandum 
of  Understanding  governs. 

2.2  This  plan  encompasses  a  joint  Air  Force/Navy  co-shared  facility  approach 
where  the  Air  Force  will  maintain  properly  skilled  personnel  at  NWC,  China  Lake 
to  accomplish  the  Air  Force  OFP  maintenance  requirements. 

2.3  It  outlines  the  scope  of  the  basic  maintenance  effort  and  the  approach 
in  accomplishing  the  task  as  agreed  to  by  both  Services. 

2.4  Further,  this  plan  outlines  the  organization,  procedures,  personnel, 
facilities,  and  hardware  requirements  to  be  furnished  by  each  Service. 

3.  SCOPE 

3.1  The  A-7D  Technical  Support  Team  will  perform  sustaining  engineering  on 
the  aircraft  integrated  Navigation  and  Weapon  Delivery  System  (NWDS)  software. 
This  function  will  involve  the  following  major  tasks: 

a.  Solution  of  operational  software  NWDC  problems. 

b.  Development  of  advanced  software  capabilities  and  improvements  to 
the  A-7D  NWDS. 
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CONTINUATION  SHEET _ DATE:  27  July  1979 


c.  Maintain  configuration  control  of  the  Tactical  Computer  Software 

Operational  Flight  Program  (OFP) ,  and  Operational  Test  Program  (OTP). 

3.2  Problem  solving  will  be  performed  to  correct  deficiencies  which  are 
discovered  during  engineering  operations  at  NWC  or  are  found  during  operational 
command  usage. 

3.3  Development  of  improvements  and  advanced  capabilities  will  be  performed 
as  required  to  refine  or  expand  the  weapon  system  capability  in  the  areas  of 
functional  performance,  flexibility,  operability,  or  maintainability.  Such 
modifications  may  involve  the  integration  of  new  avionics  and  associated 
computer  software. 

3.4  Configuration  control  of  the  OFP/OTP  is  required  to  insure  that  current 
documentation  which  meets  the  USAF  standard  is  maintained  on  each  computer 
program.  This  effort  also  insures  that  modifications  and  additions  to  each 
OFP/OTP  are  effectively  coordinated  with  the  master  aircraft  configuration 
plan. 

3.5  It  should  be  emphasized  that  this  program  provides  for  engineering  support 
of  the  A-7D  NWDS  -  the  integrated  assemblage  of  weapons,  avionics,  computer 
software,  displays,  and  controls  which  combine  to  provide  the  basic  navigation 
and  weapon  delivery  capability  of  the  aircraft.  Axuiliary  systems,  such  as 

the  Automatic  Flight  Control  System,  communications  equipment,  standby  attitude 
reference  and  the  like  are  specifically  excluded  from  this  program. 

4.  APPROACH 

4.1  The  SM  is  responsible  for  insuring  the  A-7D  NWDS  engineering  support 
program  is  properly  coordinated.  A  special  A-7D  team  staffed  with  USAF 
personnel  must  be  maintained  at  NWC.  The  team  is  co- located  with  the  A-7E 
engineering  team  to  maximize  Navy-Air  Force  interchange  and  facilitate  guidance 
and  assistance  to  the  A-7D  team. 

4.2  The  A-7D  team  will  have  the  responsibility  and  authority  for  execution  of 
all  tasks  assigned  by  OC-ALC  Computer  Resources  Branch  and  will  coordinate 
with  the  NWC  A7  Program  Manager  in  the  execution  of  those  tasks. 

4.3  Existing  A-7E  engineering  facilities  (Flight  Simulator,  System  Integration 
Lab,  Navigation  Integration  Lab,  and  special  avionic  lab  facilities)  will  be 
shared  by  the  Navy  and  Air  Force  engineering  teams.  Modification  to  these 
facilities  may  be  required  to  satisfy  unique  A-7D  requirements.  Such  changes 
will  be  defined  and  implemented  by  the  two  teams  with  the  approval  of  the 

NWC  A7  Program  Manager. 

4.4  Due  to  the  interrelationship  of  the  Navy /Air  Force  teams  in  utilizing 
available  NWC  resources  and  to  insure  reasonable  resource  availability  to 
achieve  commitments,  NWC  approval  and  concurrence  will  be  required  on  Air 
Force  dates,  milestones  and  schedules  to  accomplish  assigned  Air  Force  tasks 

as  these  dates,  milestones  and  schedules  affect  available  resources.  This  will 
allow  proper  and  reasonable  resource  scheduling  to  accomplish  both  the  NWC  and 
Air  Force  missions. 
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5.  DETAILED  REQUIREMENTS 

5 . 1  Personnel  and  Services 

5.1.1  AFLC  civilian  positions  have  been  established  at  the  Naval  Weapons 
Center  to  staff  the  A-7D  OFP  engineering  support  team. 

5.1.2  In  addition,  the  Air  Force  will  provide  necessary  maintenance  personnel 
to  support  the  project  A-7D  aircraft.  The  number  of  personnel  to  support  this 
effort  will  be  determined  by  negotiation  and  on  an  as-required  basis.  The 
aircraft,  project/liaison  officer,  and  necessary  personnel /equipment  required 
for  A-7D  aircraft  support  will  be  provided  by  the  Tactical  Air  Command. 

5.1.3  The  A-7D  OFP  engineering  support  team  OC-ALC/MMECZA  will  have  engineer¬ 
ing  responsibility  for  the  instrumentation  of  flight  test  aircraft  by  Class  II 
modification. 

5.1.4  The  Navy  will  provide  general  administrative  support  to  the  A-7D  OFP 
engineering  support  team  and  will  provide  office  materials  and  equipments 
required  by  the  team  in  support  of  A-7D  OFP  engineering  functions.  Air  Force 
funding  will  be  based  on  labor  expenditure,  materials  costs,  and  facilities 
costs. 

5.1.5  The  Navy  will  provide  documentation  update  service  in  support  of  the 
A-7D  OFP  engineering  effort  upon  request  by  OC-ALC. 

5.1.6  The  Navy  will  provide  consultation  and  assistance  to  OC-ALC/MMECZA  upon 
request,  at  a  sustaining  level  in  accordance  with  the  NWC  budget.  Air  Force 
funding  will  be  based  on  estimated  labor  expenditures  and  rates. 

5.1.7  The  Navy  will  provide  flight  test  data  reduction  services  to  OC-ALC/ 
MMECZA  with  Air  Force  costs  predicated  on  computer  utilization  time  and  Navy 
expenditures  in  support  of  those  services. 

5.1.8  The  Naval  Weapons  Center  will  provide  the  normal  transient  military 
aircraft  services  and  will  assist  in  aircraft  maintenance. 

5.2  Facilities 

5.2.1  The  A-7D  team  will  have  full  access,  on  a  scheduled  basis,  to  all  the 
facilities  of  the  A-7E  team  including  the  flight  simulator,  the  Navigation 
Integration  Laboratory,  and  the  Weapons  Integration  Laboratory.  In  turn  for 
their  use  of  these  facilities,  the  Air  Force  will  share  the  cost  of  the 
maintenance  and  operation  of  these  facilities.  Scheduling  these  facilities 
is  the  responsibility  of  the  NWC  A7  Program  Manager  and  will  be  accomplished 
based  upon  the  requirements  of  the  Navy  and  Air  Force  users.  Equal  considera¬ 
tion  will  be  given  to  the  Navy  and  Air  Force  when  scheduling  these  facilities 
during  normal  duty  hours. 

5.2.2  Flight  test  range  requirements  at  China  Lake  will  be  scheduled  through 
the  Navy  A7  Flight  Test  Engineer.  Test  range  expenses  will  be  funded  by  the 
Navy  from  AFLC  provided  funds  on  a  per-f light  basis. 
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5.3  Aircraft  and  Equipment 

5.3.1  The  Air  Force  will  provide  an  A-7D  aircraft,  properly  instrumented  for 
flight  test  purposes.  Ordnance  required  for  flight  test  will  be  provided  by 
the  Air  Force  for  A-7D  OFP  support. 

5.3.2  The  Air  Force  wi],l  provide  necessary  spare  parts  and  test  equipment  to 
support  the  aircraft  during  flight  operations. 

5.3.3  The  Air  Force  will  maintain  one  each  of  the  NWDS  components,  which  are 
peculiar  to  the  A-7D,  for  use  in  the  laboratory  facilities  at  NWC.  These  will 
include,  but  will  not  be  limited  to: 

a.  ASN-91  NWDS  Computer 

b.  Armament  System  Control  Unit  (ASCU) 

c.  AN/ASN-90  IMS 

6.  CONFIGURATION  CONTROL.  OFP/OTP  configuration  control  is  the  responsibility 
of  the  Air  Force. 

7.  REPORTS  AND  DOCUMENTATION 

7.1  NWC  shall  provide  quarterly  management  and  financial  reports  to  OC-ALC/MME. 
Content  and  format  will  be  determined  by  NWC  and  OC-ALC/MME. 

8.  funding 

8.1  The  funding  of  the  A-7D  OFP  support  program  will  be  by  means  of  a  Military 
Interdepartmental  Purchase  Request  (MIPR)  Form  DD  446  from  the  Air  Force  to 
the  Naval  Weapons  Center.  Funds  will  be  provided  either  annually  or  at  no 
shorter  intervals  than  quarterly.  The  Naval  Weapons  Center  will  forward 
monthly  Form  1080  reports  to  the  Air  Force  showing  expenditures  of  Air  Force 
Funds . 

9.  GENERAL  PROVISIONS.  Terms  and  funding  will  be  negotiated  between  the 
Services  annually  as  required  by  DOD  Directive  4000. 19M.  Termination  or  major 
modification  may  be  instituted  by  either  Service  with  a  minimum  of  six  months 
advance  notice  followed  by  joint  Service  determination  of  the  impact  on  either 
Service  and  negotiation  of  the  funding/hardware/personnel  changes  required. 
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ABBREVIATIONS 

Air  Force  Logistics  Command,  Wright-Patterson  AFB  OH 
Configuration  Control  Board 
Computer  Program  Configuration  Sub-Board 
Military  Interdepartmental  Purchase  Request 
National  Guard  Bureau 

Naval  Weapons  Center,  China  Lake,  California 
Navigation/Weapons  Delivery  System 
Navigation/Weapons  Delivery  Computer  (ASN-91) 

Oklahoma  City  Air  Logistics  Center,  Tinker  AFB,  Oklahoma 
Operational  Flight  Program 
Operational  Test  Program 
System  Manager 

Air  Force  Tactical  Air  Command,  Langley  AFB,  Virginia 
USAF  Tactical  Fighter  Weapons  Center,  Nellis  AFB,  Nevada 
Technical  Order 
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LIST  OF  DOCUMENTS 


AFR  57-4 


AFR  800-14  Vol  I 


AFR  800-14  Vol  II 


AFLC  Supplement  1 
AFR  800-14 

MIL-STD  480 


Retrofit  Configuration  Changes 

Management  of  Computer  Resources  in  Systems 

Acquisition  and  Support  Procedures  for  Computer 
Resources  in  Systems 

Acquisition  Management  -  Management  of  Cbmputer 
Resources  in  Systems 

Configuration  Control-Engineering  Changes,  Deviations 
and  Waivers 


MIL-STD  483 


MIL-STD-490 


MIL-STD  1521 


TO  00-5-15 

AFLC  Form  48 

DD  Form  1692 

AFLC  Form  252 

AFLCR/AFSCR  57-4 

DoD  Directive 
4000.19 

DoD  Directive 
4000. 19M 


Configuration  Management  Practices  for  Systems, 
Equipment,  Munitions,  and  Computer  Programs 

Specification  Practices 

Technical  Reviews  and  Audits  for  Systems,  Equipment 
and  Computer  Programs 

Air  Force  Technical  Order  System 

Configuration  Control  Board  Item  Record 

Engineering  Change  Proposal 

Publication  Change  Request 

Configuration  Management  in  the  Acquisition  Phase 

Basic  Policies  and  Principles  for  Interservice, 
Interdepartmental  and  Interagency  Support 

Defense  Retail  Interservice  Support  (DRIS)  Manual 
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A-7D  OPERATIONAL  FLIGHT  PROGRAM 
SUPPORT  PLAN  74-1A 
OCTOBER  1976 

SECTION  I 
INTRODUCTION 

1.  This  document  supersedes  Plan  74-1  revised  30  August  1974. 

2.  The  A-7D  is  a  versatile  weapon  system  providing  highly  accurate 
navigation  and  weapons  delivery  capability  for  TAG  and  ANG  through 
its  embedded  computer  system  (ECS).  The  heart  of  the  ECS  is  the 
Operational  Flight  Program  (OFP)  and  the  associated  Operational  Test 
Program  (OTP) .  Throughout  the  life  cycle  of  the  weapon  system,  the 
ECS  software  (OFP/OTP)  will  require  updating  and  maintenance  to  insure 
that  the  full  potential  of  the  weapon  system  will  be  realized  and 
operational  mission  requirements  will  be  met  in  a  timely  manner. 

3.  Three  support  alternatives  were  studied  in  the  early  phases  of  the 
A-7D  program.  These  alternatives  were:  1)  Air  Force  in-house, 

2)  Navy  Interservice,  and  3)  Contract.  The  alternative  selected  was 
an  interservice  arrangement  between  Navy  and  Air  Force  for  Air  Force 
utilization  of  the  Naval  Weapon  Center  A-7E  OFP  support  facility  at 
China  Lake,  CA.  The  initial  interservice  support  agreement  was 
consummated  in  October  1973  with  approval  by  CSAF,  Navy,  TAC,  AFLC, 
and  OC-ALC. 
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SECTION  II 

REQUIREMENTS  AND  RESPONSIBILITIES 


1.  The  organization  of  Air  Force  and  Navy  lines  of  communications  and 
command  hinge  about  the  OC-ALC  Directorate  of  Materiel  Management  (MM) 
and  the  China  Lake  Naval  Weapon  Center  (NWC) .  Chart  A-l  herein  dipicts 
the  OC-ALC/MM  A-7D  organizational  arrangement. 

2.  The  general  flow  of  actions  involving  the  ALC,  TAC,  ANG,  and  Navy  is 
shown  in  Chart  A-2 .  Included  is  contractor  involvement  when  combined 
hardware  and  software  changes  require  contractor  support. 

3.  The  OC-ALC  A-7D  System  Management  Branch,  symbol  MMSF,  is  responsible 
for  the  OFP/OTP  configuration  management  and  control  and  is  the  principal 
ALC  point  of  contact  for  OFP/OTP  deficiency  reports  and  change  requests. 

As  the  primary  responsible  office,  MMSF  will  establish,  convene,  and 
chair  a  Computer  Program  Configuration  Sub-Board  (CPCSB)  as  necessity 
dictates  and  will  ensure  accomplishment  of  the  board  functions  as 
required  by  AFR  800-14.  The  configuration  management  criteria  encompassed 
by  AFR  57-1,  AFR  57-4,  AFLCR  57-21,  MIL-STD-480,  MIL-STD-483,  and 
MIL-STD-1521  will  be  adhered  to  through  the  MMSF  actions. 

4.  Deficiency  reporting  will  be  in  accordance  with  the  criteria  of  TO 
00-35D-54  and  TO  00-5-1  with  any  peculiar  exceptions  documented  in 
Operational/Support  Configuration  Management  Procedures  (AFR  800-14  and 
AFLC  Sup  1)  generated  by  the  SM,  TAC  and  ANG. 

5.  The  detailed  AF-Navy  relationships  are  contained  in  Annex  A  hereto. 

(Not  included  here.) 

6.  The  TAC  support/functional  details  are  contained  in  Annex  B  hereto. 

(Not  included  here.) 

7.  The  OC-ALC/MMECZA  A-7D  0FP  engineering  support  team,  China  Lake,  CA, 
will  be  responsive  to  engineering  support  requests  and  directions 
provided  to  them  by  OC-ALC/MMEC  as  received  from  0C-ALC/MMSF. 

8.  Joint  software/hardware/system  modifications  will  require  joint  efforts 
of  OC-ALC/MME  and  OC-ALC/MMS  engineering.  MMSF  will  be  the  office  of 
primary  responsibility  to  manage  the  overall  effort,  call  upon  other 
organizations  as  required,  establish  agreements,  and  ensure  that  the 
totality  of  modification  requirements  is  covered. 
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A-7D  OFP  CHANGE 

FLOW 

STEP 

TAC,  ANG 

TOFNTTFTf'ATTnN  j 

r  1 

PHASE 

1  - 

- 1 

1  OFP  CHANCE 

n.£iV^  u  1 

i 

1 

MMS/MME 

SCREENING 

PHASE 


MME/TAC/ANG/MMS 
NWC  SUPPORT 
DEFINITION 
PHASE 


REJECT 


- VALIDITY  > 

J  CONTINUE 

ANALYSIS,  FEASIBILITY, 
COSTS,  ALTERNATIVES, 
IMPACTS 


CPCSB/CCB 
MMM/MMS 
GO-AHEAD 
APPROVAL  PHASE 


mme/nwc* 

IMPLEMENTATION 
DESIGN  PHASE 


mme/tac/ang/nwc* 

IMPLEMENTATION 
TEST  PHASE 


MME/MMS* 


^  CCB  ^ 
.EVALUATE . 


REFER 


""CPCSB  \ 
.  EVALUATE . 


APPROVE 


APPROVE 


CHART  A- 2 

*Responsible  for  review  and  approval  of  OFP 
changes  accomplished  by  contractors  as  a 
result  of  a  hardware/software  modification. 
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STEP 

1.  Identification  of  need  for  change  due  to  deficiencies  or  operational 
requirements.  Identification  through  TO  00-35D-54,  TO  00-5-1  system, 

ROC,  etc. 

2.  Assessment  of  requirement  validity  through  initial  analysis.  Impacts 
if  not  implemented.  Determination  of  type  of  modification,  forms  and 
data  required,  planned  approach. 

3.  Detailed  analysis  and  study;  impacts  on  hardware,  manuals,  data,  AGE, 
etc;  alternatives  with  pros  and  cons;  cost  estimates;  ECP  information; 
Form  44  or  48  information. 

4.  Presentation  before  CPCSB.  Software  change  only  and  no  funds  required  - 
approve  or  disapprove.  Funds  required  or  hardware  implications  -  dis¬ 
approve  or  refer  to  CCB  with  information  and  recommendation. 

5.  If  approved  (and  funded  if  funds  required),  design,  code,  and  debug 
preparatory  to  full  testing. 

6.  Run  test  series  to  prove  acceptability  of  modified  software  and  finalize. 

7.  Reproduce  and  distribute  final  program  configuration,  update  manuals  and 
data. 

NOTE:  Determination  of  associated  hardware  modification  should  occur  at  2 
or  3.  In  this  instance  or  if  an  initial  hardware  modification  requirement 
entails  an  associated  software  change,  joint  MMS/MME  planning  will  be  required. 
Planning  and  coordination  under  MMS  as  OPR  will  provide  for  organic  or  contract 
or  mixed  efforts  for  both  software  and  hardware.  For  contract  or  mixed  efforts, 
firm  relationships  between  the  Air  Force  organizations  and  the  contractor  will 
be  established  and  contractually  specified. 
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ABBREVIATIONS 

ABBREVIATION 

DEFINITION 

AF 

Air  Force 

AFLC 

Air  Force  Logistics  Command 

AFLCR 

Air  Force  Logistics  Command  Regulation 

AFR 

Air  Force  Regulation 

ANG 

Air  National  Guard 

ALC 

Air  Logistic  Center 

CPCSB 

Computer  Program  Configuration  Sub-Board 

CSAF 

Chief  of  Staff  Air  Force 

ECS 

Embedded  Computer  System 

MGMT 

Management 

NWC 

Naval  Weapons  Center 

OC-ALC 

Oklahoma  City  Air  Logistics  Center 

OFP 

Operational  Flight  Program 

OTP 

Operational  Test  Program 

ROC 

Required  Operational  Capability 

SM 

System  Manager 

TAC 

Tactical  Air  Command 

TO 

Technical  Order 
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Change  Requirement 


Method  of  Transmittal 


HARDWARE 


Feasibility  Analysis 

Preliminary  Design  &  Out-of-Line  Code 
Preliminary  documentation 
Preliminary  Test  Plans 
Preliminary  User  Guide 


Computer  Program  Configuration  Sub-Board 
Design  Review,  Finalize  Design 


Assemble  In-Line  Code 
Final  Documentation 
Final  Verification  &  Validation  Plan 
Final  User  Guide 


Verification 

Hardware  Integration 


Validation  and  OT&E 

Simulation,  Lab,  and  aircraft  tests 


Publish 
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TACTICAL 


CHANGE 

REQUEST 


ANALYTICAL 


A  STUDY/ 
REPORT 


FEASIBLE 


APPROVED 


ASSEMBLE 


VERIFY 


VALIDATE 


PUBLISH 
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CHANGE  CONTROL  METHODS 


During  the  initial  feasibility  analysis  of  any  individual  change,  a  "Hand¬ 
load  (out-of-line  patch)  is  completed.  The  "Handloads"  serve  as  an  index  to  the 
individual  changes  and  they  directly  transform  into  an  editor  source  that  is  used 
to  edit  the  program  source  code  to  include  the  CPCSB  approved  changes  in  line. 

A  "compare"  program  is  then  used  to  flag  all  additions  and/or  deletions  between 
the  old  assembled  program  and  the  new  assembled  program.  The  output  of  the 
"compare"  is  checked  against  the  original  handload  to  ensure  proper  incorporation. 


CHANGE  REQUEST 


EDIT  SOURCE 


COMPARE  ASSEMBLED 
PROGRAMS 


COMPARE  TO 
HANDLOAD 


PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES  (Cont) _ DATE:  27  July  1979 

STRUCTURED  DESIGN?  -  DESCRIBE 

In-line  changes  are  not  structured.  Stand-alone  routines  are  top-down  structured. 

STRUCTURED  PROGRAMMING?  -  DESCRIBE 

See  above. 

CODING  GUIDELINES: 

Coding  guidelines  are  described  on  pages  A-25  through  A-36,  especially  pp.  28ff. 

CHANGE  ENTRY  METHODS: 

CRT  terminal  is  the  primary  method. 

SCHEDULE: 

Formal  change  schedules  are  issued. 

REPORTING: 

Weekly  status  reports  are  provided . 

COMMENTS: 
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SOFTWARE  GUIDELINE 


May  21,  1979 


Revision  4 


INTRODUCTION 

This  guideline  reviews  several  aspects  of  software  documentation  and  coding 
techniques  that  have  a  bearing  on  the  overall  quality  of  software  developed  and 
on  the  eventual  maintenance  costs.  Section  I  includes  documentation  needed  for 
review  during  the  definition  and  design  phase,  test  planning  during  the  integration 
and  test  phase,  and  user/maintainer  understanding  during  production  usage.  It  is 
based  on  numerous  previous  documentation  guidelines  and  on  practical  experience. 

The  primary  references  are  a  simplified  version  of  DOD  Standard  7935. 1-S  and  the 
NAVAIR  SOFTWARE  MANAGEMENT  MANUAL  (Preliminary). 

Section  II  covers  Intraprogram  Documentation  (comments,  program  header),  and 
is  based  on  numerous  different  header  styles  in  use  at  the  NWC  and  elsewhere.  It 
is  also  based  on  the  article  by  Flores  regarding  commenting  within  programs. 

Section  III  covers  detailed  coding  guidelines  including  variable  naming, 
recommended  coding  constructs,  etc. 


At  this  time,  this  guideline  is  intended  for  use  by  programming  teams  to 
provide  them  with  a  "menu"  of  recommended  approaches,  formats,  and  detailed  coding 
rules  that  may  be  selected  for  that  specific  projects. 

This  document  was  adapted  and  reviewed  by  Richard  Breisch,  Steve  Underwood, 
and  Richard  Fryer,  with  inputs  from  many  others.  The  contributions  of  the  A-7 
team  led  by  Harvey  Nelson  and  the  F-18  team  led  by  Roy  Law  deserve  special  note. 
Many  other  documents  were  reviewed  and  good  ideas  "plagiarized,"  including  the  DAIS 
software  development  standard,  the  Federal  Information  Processing  Standard  for 
documentation  of  computer  programs,  and  the  DOD  Automated  Data  System  Documentation 
Standard  (7935. IS).  The  similarity  of  these  last  two  documents,  and  the  potential 
need  to  conform  to  this  format  in  future  DOD  programs  suggest  our  use  of  it  where 
applicable. 
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SECTION  I 

DEVELOPMENT  AND  DOCUMENTATION  GUIDELINES 

This  section  discusses  the  system  documentation  needed  other  than  that 
provided  in  the  actual  code.  For  the  actual  documents  to  be  provided,  the  Federal 
Information  Processing  Standards  Publication  Number  38  is  recommended  as  a  guide¬ 
line.  Specific  examples  are  selected  from  this  publication.  This  document  does 
not  cover  the  detailed  format  of  documentation  that  may  be  used  in  Design  Reviews. 
For  this  area,  the  NAVAIRSYSCOM  SOFTWARE  MANAGEMENT  MANUAL  is  the  primary  reference 
As  a  backup  to  this  manual,  MIL-STD-1521 ,  "Technical  Reviews  and  Audits  For  Systems 
Equipment,  and  Computer  Programs"  is  an  excellent  reference. 

FRONT  END  DOCUMENTATION  AND  REVIEWS 

During  the  pre-coding  phase,  requirements  are  solidified,  preliminary  design 
is  conducted,  and  many  design  tradeoffs  are  carried  out.  This  phase  of  the  system 
development  process  plays  a  key  role  in  the  ultimate  quality  of  the  product,  and 
in  identifying  commonality  between  various  projects. 

Functional  Requirements  provide  a  definition  of  the  system  to  be  produced 
in  terms  that  are  generally  independent  of  the  programming  details,  and  provide  a 
basis  for  mutual  understanding  to  the  various  participants  in  a  system  development 
effort.  These  requirements  describe  the  behavior  of  the  system  to  be  developed, 
with  emphasis  typically  on  the  operating  behavior  of  the  system  and  the  operating 
environment.  Critical  schedules  may  also  be  included.  The  documentation  produced 
will  be  reviewed  by  users  and  other  team  members,  typically  in  a  design  review 
and/or  by  review  of  a  draft  requirements  document.  The  requirements  document  should 
address  in  general  the  topics  in  Section  3.1  of  the  reference  document,  FIPS  PUB  38. 

The  review  of  requirements  may  take  the  form  of  a  System  Requirements  Review. 
The  purpose  of  this  review,  as  defined  in  the  Software  Management  Manual,  is  to 
determine  the  adequacy  of  the  requirements  definition,  ensure  that  unrealistic 
requirements  are  not  imposed,  and  provide  a  forum  for  discussion  of  test  plans  and 
other  software  development  planning. 

A  System  Design  Review,  which  might  be  combined  with  the  previous  review,  will 
also  consider  the  quality  of  the  requirements  (completeness,  efficiency,  etc.), 
ensure  that  program  risks  are  identified  for  program  planning  purposes,  and  will 
address  needed  support  efforts  such  as  Driver  programs.  Test  data  bases,  Design 
Verification  efforts,  performance  monitoring,  testing,  team  development,  testing 
approach,  program  support  libraries,  and  evaluation  of  algorithms. 

Specifications  and/or  Detailed  Requirements  are  developed  in  systems  where 


the  software  implications  of  the  requirements  document  are  not  completely  self- 
explanatory.  It  will  include  information  such  as  operating  environment,  coding 
guidelines  selected,  etc.  These  documents  are  discussed  in  Sections  3.3  and  3.4  of 
the  reference  document. 


The  software  design  process  may  be  reviewed  at  two  other  traditional  and 
significant  points  in  the  development  cycle.  The  first  of  these  is  called  the 
Preliminary  Design  Review.  This  review  is  held  to  review  the  general  program 
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description,  the  utilization  of  I/O,  detailed  requirements  provided  since  the 
previous  documents  or  reviews,  Q/A  provisions,  details  of  Test  requirements  and 
plans,  interface  requirements,  etc. 

A  review  following  the  Preliminary  review  is  held  if  required  to  review  all 
documents  required  prior  to  start  of  coding,  such  as  the  subsystem  specification, 
the  data  base  document,  etc.  This  Critical  Design  Review  will  also  cover  the 
software  interface  between  modules,  software/hardware  detailed  interface  require¬ 
ments,  data  base  interactions  (especially  for  software  tools,  etc.). 

Other  documents  that  may  be  initiated  in  the  pre-coding  phase  are  the 
Data  Requirements/Data  Base  Specification  (see  Sections  3.2  and  3.5  of  FIPS  PUB  38) 
and  the  Test  Plan  (Section  3.9).  While  these  documents  may  not  be  completed 
until  the  coding  and  testing  is  complete,  a  draft  of  the  best  available  information 
in  these  areas  can  be  a  great  aid  during  software  development. 

FOLLOW-ON  DOCUMENTATION 

A  Program  Maintenance  Manual  provides  the  information  needed  to  provide  detailed 
data  on  the  implementation  of  the  requirements  and  "how  to  make  it  work"  type  data. 
Section  3.8  of  the  reference  discusses  this. 

A  Users  Manual  is  appropriate  for  complete  systems  for  which  the  user  interface  is 
a  major  part  of  the  operation,  such  as  in  data  reduction  and  other  software  tools. 
It  required,  the  format  suggested  appears  in  Section  3.6. 


i  iiHUti.v  "  •"-Hilton 
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SECTION  II 


INTRAPROGRAM  DOCUMENTATION 


PROGRAM  HEADER 

The  header  comments  should  provide  the  necessary  information  to  establish  the 
data  interfaces  to  this  routine;  proper  usage  of  this  routine,  and  what  is  to  be 
accomplished  by  the  routine.  The  header  format  is  shown  in  Figure  A-l  (on  p.  A-29) , 
and  a  sample  header  appears  in  Figure's  A-2a  and  A-2b  (pp.  A-3Q  and  A-31) . 

COMMENT  GUIDELINES 


Comments  within  a  program  are  used  by  the  writer  of  the  program  before  it  is 
turned  over  to  the  user.  During  this  period,  comments  can  help  him  to  recall 
details  of  the  requirements  or  the  algorithms  that  he  has  chosen,  or  to  reflect 
areas  that  he  expects  to  be  modified  at  a  later  date. 

Comments  are  also  used  to' indicate  how  a  module  may  be  dependent  on  particular 
assumptions  made;  for  example  aspects  that  are  dependent  on  the  host  computer. 

The  main  issue  to  emphasize  for  comments  is  to  assure  that  the  intended 
message  is  clear  in  content  and  in  appearance  within  the  code.  The  comments  may  be 
grouped  away  from  the  code  by  positioning  them  to  the  right  of  the  line,  or  by 
using  separators  or  boxes,  as  shown  in  Figure  A-3  (p .  A-32) . 

Blank  comment  lines  should  be  used  to  improve  readibility  (keep  the  comments 
separated  from  the  code).  Blank  comment  lines  also  serve  to  highlight  major 
changes  in  flow  in  the  program,  such  as  subprogram  calls  and  loops. 

Columns  73-80  of  a  FORTRAN  source  statement  can  be  ignored  by  the  compiler, 
and  hence  are  available  for  documentation.  This  field  may  be  used  for  detailed 
documentation  of  program  changes.  With  each  statement  altered  or  added  (once  a 
module  had  gone  under  configuration  control),  the  programmer's  initials  and  the 
date  of  the  change  should  be  entered  in  this  field  (alternately,  the  related 
Specification  Change  Notice  or  Notice  of  Change  may  be  entered,  at  the  project's 
discretion) . 
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DESCRIPTION: 

This  section  describes  the  function  of  the  routine  and  what  is  done. 

The  why  will  be  explained  in  related  documentation  as  described  in 
Section  I  of  this  report.  In  unusual  cases,  the  programmer  may 
determine  that  additional  information  be  included  in  the  header. 

MODIFICATIONS: 

This  field  provides  a  continuous  history  of  who  modified  the  routine, 
when,  and  for  what  purpose.  The  CHANGE  field  may  refer  to  the 
Specification  Change  Notice  or  another  configuration  management 
numbering  scheme.  See  the  example  in  Figure  2a. 

REMARKS/QUESTIONS : 

This  field  is  left  to  permit  the  user  to  call  attention  to  any  part 
of  the  code  that  seems  important  if  the  configuration  management/quality 
assurance  scheme  does  not  permit  that  data  to  be  retained  in  a  highly 
visible  form. 

SUBPROGRAMS  CALLED: 

This  section  provides  the  names  in  alphabetical  order  and  the  primary 
purpose  (as  used)  for  each  subprogram/procedure  called.  The  comment 
will  refer  not  necessarily  to  the  prime  capability  of  the  module  called, 
but  to  the  use  that  it  is  referred  for  in  this  routine. 

INPUTS : 

This  field  lists  in  alphabetical  order  all  variables  that  must  be  defined 
before  this  routine  is  called  (constants  or  parameters;  whether  in  a 
calling  list  or  in  COMMON) .  The  input  definition  will  be  extracted  from 
the  standard  defined  data  base;  that  is,  a  special  meaning  will  not  be 
given  to  these  variables  in  this  comment  section.  If  any  special  usage 
is  accomplished,  it  should  be  described  In  the  DESCRIPTION. 

OUTPUTS : 

This  section  is  the  same  as  for  INPUTS,  except  that  the  named  variables 
do  not  require  initialization  prior  to  calling  this  routine  (normally). 
Any  variable  that  is  used  for  both  input  and  output  (that  is,  modified) 
will  appear  in  both  lists. 

LOCAL  VARIABLES: 

This  section  covers  temporary  variables  (used  only  during  a  single 
execution  of  this  subprogram)  and  those  that  are  only  used  in  this  sub¬ 
program,  but  that  must  be  retained  from  one  call  of  the  subprogram  to 
the  next.  These  latter  type  will  be  placed  in  labeled  COMMON  to  meet 
portability  objectives. 

Figure  1.  Header  Description. 


33 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  27  July  1979 


********************************************************************** 
SUBROUTINE  SAMPLE  (X) 

********************************************************************** 

DESCRIPTION 

THIS  ROUTINE  IS  A  SAMPLE  FOR  DOCUMENTATION  PURPOSES  FOR  THE  STYLE 
GUIDE 

THIS  ROUTINE  USES  NEWTON’S  METHOD  TO  CALCULATE  THE  SQJARE  ROOT  OF  ANY 
NUMBER  BETWEEN  1.  AND  100. 

IF  THE  NUMBER  INPUT  IS  OUTSIDE  THESE  LIMITS,  AN  ERROR  MESSAGE  WILL 
BE  PRINTED  OUT 

IF  THE  NUMBER  IS  INSIDE  THESE  LIMITS,  THE  VARLA3LE  INPUT  WILL  BE 
RETURNED  AS  THE  SQUARE  ROOT  OF  THE  INPUT  NUMBER. 

*********************+************************************************ 

MODIFICATIONS 


n 

C 

c 

c 

DATE 

AUTHOR 

CODS 

PHCNE 

CHANGE 

PURPOSE 

1  MAY  79 

S.  UNDERWOOD 

SCI 

446-3501 

ORIGINAL  AUTHOR 

c 

c 

8  JIJL  79 

F.  LLOYD 

3194 

X5425 

13 

IMPROVE  SQUARE 
ROOT  ALGORITHM 

c 

17  DEC  79 

R.  FRYER 

3145 

X5441 

29 

VARIABLE  NAME 

CHANGES 

★  **  *  ★*****★**★****★******★★*★***★**********'******★*'*************•*  ****** 
REMARKS/QUESTIONS 


C 

c 
c 
c 
c 
c 

C  NOTE:  THE  ACCURACY  SHOULD  BE  .ADDED  TO  THE  REMARKS  SECTION.  WAT  IS 
C  IT?  R.  FRYER  28  APR  79 
C 

f*  **★**★★★★*•*'***★•***★*★****  'k  *  *  4r  *  -A- *  A”  *******  -y.  ****************************** 

c 

c  SUBPROGRAMS  CALLED 
r 

C  ERRCK  -  CHECKS  FOR  ERROR  IN  THE  INPUT  VARIABLE  LIMITS 
C  NEWTT  «  PERFORMS  CAT  NEWTONIAN  ITERATION 

C 
C 
C 


*********************************************************************** 


t  A-2a.  Sample  Her  Her  (lop) 
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C  INPUTS 
C 

C  ERR  =  ERROR  TOLERANCE  («*S) 

C  X  =  I/O  PARAMETER  PASSED  THROUGH  THE  CALL  STATEMENT  (R*4) 

C 

Q  ********************************************************************** 

C. 

C  OUTPUTS : 

C 

C  X  =1/0  PARAMETER  PASSED  THROUGH  THE  CALL  STATEMENT  (R*4) 

C 

c  ********************************************************************** 

c 

C  LOCAL  VARIABLES: 

C 

C  V  =  INTERNAL  VERSION  0?  X  DURING  THE  SQUARE  ROOT  COMPUTATION 

C  (R*4) 

C 

c  ********************************************************************** 

c 


Figure  A-2b  Header  Sample  (bottom) 
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Q  ★****’*★****'***** '*Ar**x******-***:^**************************'****r********* 

C  THTS  BLOCK  O--'  CODS ,  WRITTEN  IN  FLEX,  IS  COMPRISED  OF  THREE  SECTIONS 
C 

C  SECTION  A  PLOTS  THE  AXIS  WITH  TIC  MARKS 
C  SFTTTON  B  ADJUSTS  TLX  'CALC  0?  THE  NUMBERS 

C  (IF  REQUIRED)  SO  THAT  TIC  MARKS  HAVE  R5.ADA3LS  LABELS 

C  SECTION  GENERATES  THE  EXPONENT  LABELS  AMD  THE  NUMBERS 

Q  *★★★★★★★****★**★★  r  ★★  *  x  **★***•*■  *  *  *  4c  *c  k-k  *  *  *  *  k  >•>.  kkk  ★★*•★******■*■**■★******■  irk  kk 

c 


IF  (NC  .LT.  0)  SIGN  NEC 


ANGR  =  ANGLE*0 .  O'  7-'532r>- 
CANG  -  COS  (.ANGR) 

SANG  =  CDs'  (ANGR) 

SECTION  B  COMMENTS: 


Cl 

FROM  THE  ORIGINAL  IN  AD 

cl 

cl 

IF  DX  >-  0. 1  THEN 

cl 

IF  DX  •;  100.  iHEN 

n\ 

EXP  :=  0. 

cl 

ELSE 

cl 

WHILE  DX  >  1C 

cl 

EX?  :=  EX 

cl 

DX  :=  DX/ 

Cl 

END  LOOC1 

C! 

END  Ir 

Cl 

ELSE 

r> ' 

WHILE  DX  <  i.O 

Cl 

EXP  EXP 

cl 

DX  :=  DX  *  10 

cl 

END  LOOP 

1  c! 

END  IF 

COMPUTE  SOME  CONSTANTS 
REGARDLESS  0?  PARAMETERS  INPUT 
THESE  COMMENTS  START  OUT  FROM 
THE  CODE  3Y  BLOCKING  THEM  TO 
raE  RIGHT  SIDS  OF  THE  RAGE 


PSEUDO  CODE  FOLLOWS 


WHEN  (DX  .GE.  0.1) 

WHEN  (DX  .LT.  100.)  EX?  -  0.0 
ELSE  WHILE  (DX  .Gr.  10.0) 

EXP  =  EXP  -  1.0 

dx  =  nx/io.o 

FIN 

FIN 

ELSE  WHILE  (DX  .LT.  1.0) 

EXP  =  EXP  +  1.0 
DX  =  DX  *  10. 0 
FIN 

FIN 

END  OF  S 

Figuri  A-3 .Commenting  Styles  for  Readability, 
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SECTION  III 

CODING  GUIDELINES  AND  STYLE 


The  guidelines  presented  in  this  section  are  intended  to  achieve  a  uniformity 
of  coding  style  that  supports  the  major  principles  of  structured  and  readable  code. 
In  general,  the  "rules"  that  follow  are  intended  to  improve  program  layout  (and 
in  some  cases,  program  design)  with  the  long-term  goal  of  reducing  maintenance 
labor.  Programs  will  be  easier  to  read  if  a  standard  format  is  generally  used. 
Further,  the  golden  rule  of  computer  science  can  be  applied:  If  the  rules  can  be 
formalized,  then  the  computer  can  apply  them  for  us. 

In  general,  the  following  apply: 

Format  so  that  the  important  parts  stand  out 

Show  the  scope  of  control  of  an  important  command 

Select  names  by  a  formula  or  mnemonic  that  enhances  understanding 

Specific  rules  follow. 

Variable  Names 

Variable  names  should  be  descriptive.  Do  not  use  "cute"  names  unless 
they  are  foremost  descriptive.  A  variable  name  should  have  a  unique 
definition.  If  temporary  variable  names  have  no  significance  in 
themselves,  don't  attempt  to  give  them  significant  names;  "TEMPL," 
etc.  may  be  sufficient.  Don't  use  the  same  name  for  an  intermediate 
value  and  the  final  value  of  a  variable.  Beware  of  changing  variable 
names  by  only  one  letter  at  the  end.  For  example,  "AMAC"  and  "AMACH" 
sound  the  same  and  so  may  be  confused,  while  "TEMPI"  and  "TEMP2"  are 
probably  O.K.  Do  not  break  variable  names  when  using  continuation 
lines. 

Program  Flow 

Program  flow  should  be  from  top  to  bottom  (no  backware  referencing 
GO  TO's).  Do  not  branch  to  a  section  of  code  and  then  return  to 
save  a  few  statements.  If  appropriate,  use  a  subprogram  or  procedure 
(memory  is  usually  cheap) . 

Spacing 

Spaces  are  recommended  before  and  after  each  operator  or  delimiter 
(=+-*/<>(  .OR.  .AND.  )  etc.  as  needed  to 
improve  readability. 

Examples : 

I  «*  2*J  +  3*K 


IF  (  A  .OR.  B  ) 

IF  (  A.EO.B  .OR.  C.EQ.D  ) 
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DO  Loops 


Statements  that  control  multiple  lines  of  code  should  show  scope  of  the 
controlling  statement  by  Indentation.  For  the  DO  loop,  the  statements 
within  the  loop  should  be  indented,  (at  least  3  spaces)  so  that  the  key  word 
stands  out,  and  closed  with  a  CONTINUE  that  begins  on  the  same  column  as 
the  DO  loop.  Nested  DO  loops  should  be  further  indented,  and  should 
terminate  on  different  CONTINUE  statements. 


Example : 


DO  30  I  =  1,N 
SUM(I)  =  0.0 


INSERT  BLANK  COMMENT  BEFORE  DO  AND  AFTER  CONT. 


DO  20  J  =  1,N 

SUM(I)  =  SUM(I)  +  X(I,J) 
20  CONTINUE 
C 

30  CONTINUE 

C 


Array  Indices 


Zero  and  negative  indicies  are  allowed  (as  in  FORTRAN  77).  For  some  data 
arrays,  lower  and  upper  limits  can  be  chosen  to  improve  readability;  for 
example,  when  data  items  are  numbered  elsewhere  in  a  certain  order. 

Example: 


READ  THE  BUS  INPUT  ARRAY 
USING  FCN  GETWRD  WITH  ID=BUS 


NOTE  THAT  THERE  ARE  21  VALUES 


DIMENSION  A(0 : 20) 

DO  10  I  =  0,20 

A(I)  =  GETWRD (BUS) 
10  CONTINUE 


CONTINUE  Statements 

CONTINUE  statements  will  be  used  only  with  DO  loops. 

Large  DATA  Statements 

Singly  dimensioned  data  arrays  will  have  entries  grouped  into  sets  of 
3,  4,  or  5  to  a  line  to  facilitate  reading.  Thus  it  will  be  easy  to  find 
the  nth  item  without  counting  each  item.  Do  not  break  values  by  using 
continuation  lines.  For  multiply  dimensioned  arrays,  pick  the  number  per 
line  to  facilitate  location  of  a  specific  element.  Implied  DO  loops  are 
allowed  to  initialize  full  arrays. 
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Branching  and  Statement  Numbers 

Minimize  branches  by  using  control  structures  suited  to  the  problem  at  hand. 
Statement  numbers  will  be  in  increasing  order  (the  use  of  a  program  such 
as  TIDY  to  achieve  this  is  an  approved  method) .  Unused  statement  numbers 
may  be  confusing  and  so  should  usually  be  avoided.  Unless  defined  otherwise, 
statement  numbers  should  start  at  100  and  increase  by  10. 

Conditionals 

Avoid  arithmetic  IF  statements.  Avoid  negative  logic  except  where  it 
clearly  improves  comprehension.  Readability  can  be  improved  if  two-state 
variables  (i.e.  switch  on  or  off)  are  represented  as  LOGICAL  variables 
and  not  numerical  (e.g.  0,  1). 

COMMON  Blocks 

COMMON  blocks  will  be  in  alphabetical  order  within  a  module.  As  blocks 
are  modified  or  created,  the  names  within  the  blocks  will  also  be  in 
alphabetical  order.  If  all  variables  within  a  block  will  not  fit  on  one 
line,  a  second  COMMON  block  should  be  defined.  Begin  all  variable  lists 
in  column  23  and  insert  blanks  after  commas. 

Col.  07  Col.  23 

I  l 

COMMON  /BLKl/  ALPHA,  BETA 

COMMON  /BLOCK  2/  SAFE,  WAY 

COMMON  /SUPER/  AL,  BERT,  SONS 

C  NOTICE  THE  CAREFUL  AVOIDENCE 

C  OF  "CUTE"  NAMES 

Parentheses 

Use  parentheses  freely  to  avoid  ambiguous  constructions. 

A**B**C  should  be  (A**B)**C 

A/B*C  should  be  (A/B)*C 

Constants  and  Variable  Initialization 

All  constants  and  variables  that  require  initialization  should  be  set 
in  an  initialization  routine. 
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SUBPROGRAM  Lengths 

The  length  of  any  subprogram,  function,  or  procedure  should  be  designed 
to  convey  one  major  computation  but,  should  not  exceed  nominally  two  or 
three  pages  of  code,  including  comments,  but  excluding  the  header. 
However,  the  generous  spacing  of  code  (white  space)  is  preferred  to 
short  dense  listings.  Keep  ease  of  reading  and  understanding  in  mind  . 
Avoid  consistently  short  or  long  routines. 


Deviations  from  the  above  guidelines  should  be  discussed  with  the  software 
development  team,  including  the  quality  assurance  activity  (if  any)  to  assure 
that  quality,  maintenance,  and  readability  goals  are  not  compromised. 
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DOCUMENTATION: 

REQUIREMENTS:  Requirements  documentation  was  never  published  for  the  A-7D. 
See  p.  A-26  for  guidelines. 

DESIGN:  Design  documentation  was  last  published  in  October  1978. 

See  p.  A-26  for  guidelines. 

USER:  User  documentation  was  last  published  in  October  1978. 


PROGRAM  PROBLEM  REPORTING  SYSTEM: 

A  program  problem  repprt  form  is  shown  on  page  A-38.  This  is  generated  by  any 
user  or  analyst.  After  analysis,  it  is  referred  to  the  appropriate  configuration 
manager  (OFP,  hardware,  simulation  software).  The  configuration  manager  generates 
the  change  notice  shown  on  page  A-39. 


COMMENTS: 


1 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  27  July  1979 


PROPOSED  CHANGE/PROBLEM  REPORT 


Prepared 

by 


date  org/code  ext  I  Priority  emergency 


urgent 

routine 


PC/PR 
number 
sheet  of 


ITEMS  EFFECTED  assembly/ 

Problem/  [ P/S  |  H/S  subroutine 

Solution 
Hardware/ 

Software 


PROPOSED  SOLUTION  Prepared 
by 


module/algorithm/ 

common 


date  org/code  ext  RELATED  PC/PR 


ESTIMATE  OF  RESOURCES  REQUIRED  FACILITY  MANAGER  date 

(manpower,  schedule,  computer 
time,  etc.) 

_ rejected  _ accepted 


REVIEW  Technical  CM 

_ accepted  as  reviewed  concurrer 

_ accepted  minor  revisions 

_ review  needed  _ cancelled 

Comments : 


ACTUAL  PRIORITY 

_ emergency 

_ urgent 

routine 


PRELIMINARY  TESTING  COMPLETED 

Corrector 

Technical  Concurrer 

CM  date 

UPDATE  FORM  FILED 
date  Corrector 


UPDATE  MADE 
CM 


date 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET _ DATE:  27  July  1979 

NOTICE  OF  CHANGE 

Corrector  date  org/code  ext  Notice  of  Change 

number 


ITEMS  EFFECTED  BY  CHANGE  RELATED  PROPOSED  CHANGE 


This  notice  authorizes  and  provides  a  precise  description  of  Hardware, 
Software  and  documentation  changes.  In  addition  to  the  basic  description 
of  the  change,  provide  the  following  data. 

A.  Hardware:  provide  a  precise  "FROM- TO"  drawing  in  the  block. 

B.  Software:  provide  a  source  coding  with  marked  changes. 

C.  Documentation:  provide  a  list  of  change  pages  and  effective  data. 

DESCRIPTION  OF  CHANGE 


*  It  vflM.'J  i*V* jr*»- 


<*  j.1'  wvi*  ’ 


PREDICTIVE  SOFTWARE  COST  MODEL 

PERSONNEL  DESCRIPTION  DATE:  27  July  1979 


DESCRIPTION  OF  SKILL  LEVEL  AND  TYPE  (AF/CS7C0NT)  OF  PERSONNEL  MAINTAINING  THIS  PACKAGE 


Position 

Grade 

Degree 

SUPV  Electronic  Engr. 

GS-13 

BS,  1968 
MS 

Mathematician 

GS-12 

BS,  1965 
MS 

Computer  Scientist 

GS-11 

BS,  1970 

Equipment  Specialist 
(Avionics) 

GS-11 

AA 

Computer  Operator 

GS-09 

BA,  1966 

Clerk- Typist 

GS-04 

Total  experience  with  A-7  is  37  manyears. 
Total  experience  with  S/W  is  18  manyears. 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  - 

BUILDINGS: 


2 

Weapons  Integration  Lab  -  935  ft 

Mission  Simulator  -  644  ft^ 

Navigation  Lab  -  1,240  ft2 

Office  Space  -  1,680  ft2 


FACILITIES 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  -  FACILITIES  (Cont) 


COMPUTER  FACILITIES  (Type,  Quantity,  Application,  Cost  &  Usage) 


DATE:  27  July  1979 


DEC  PDP  11/60 


DEC  PDP  11/45 


Simulation  in  Weapons 
Integration  Lab 

Software  Development 
and  Data  Reduction 


DEC  PDP  11/45 


Graphics  in  Mission 
Simulator  Laboratory 


DEC  PDP  11/34  (11/10,  11/05)  3 

Honeywell  SIGMA  V  1 


Hewlett  Packard  9830 


TC-2  Control  &  Display 

Simulation  in  Mission 
Simulator,  Software 
Development  Data  Reduction 

Office  calculator 

Management  Tools 

Some  Plotting  Capability 


Only  CPUs  are  listed.  See  p.  A-43  for  peripherals  and  interfaces. 

pp.  A-44  and  A-45  give  equipment  prices  for  various  equipment  plus 
software  for  a  facility  that  would  have  capabilities  comparable  to 
the  existing  weapons  laboratory. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  -  Computer  Facilities _ DATE:  27  July  1979 


EQUIPMENT 


WPS  LAB  PDP  11/60  (192K) ,  11/45  (32K),  11/10  (16K),  11/05  (4K) 

4  ADM. 3  Terminals  +  (16  remote) 

DEC  Writer 
Tape  Drive 

4  Disk  Drives  ( 7M  BYTE  total) 

2  Dual  Floppy 
2  Punch  Tape  Readers 
Versatec  Printer 

1  TC-2 

Custom  Interfaces 

SIM  LAB  Honeywell  15  64K 

2  Tape  Drives 

2  Disk  (48M  BYTES  total) 

Line  Printer 
Card  Reader 
TY  35 

Tape  Punch/Reader 
Key  Punch 
Custom  Interfaces 

PDP  11/45  (32K) 

Disk 

Tape  Drive 
Versatic  Printer 
Vector  General 
Tektronic  4014 
CADU 
TC-2 

NAV  LAB  PDP  11/45  (32K) ,  11/60  (192K) ,  11/10  (16K) 

Tape  Drive 
Disk 

Punch  Tape  Reader 

Custom  Interfaces  &  A/C  equipment 

TC-2 

OFFICE  2  ADM- 3  Terminals 

1  Diablo  Terminal 
HP  9830 
HP  Plotter 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET _ DATE:  27  July 


SHOPPING  LIST 

A-7D  Computer  Laboratory  April  9,  1979 


BASIC  SYSTEM 

This  system  is  configured  to  provide  the  capability  to  assemble  an 
OFP,  run  normal  utilities  (editor,  file  maintainer,  etc.),  provide 
short  listings,  and  provide  DUMCAD/MINI-SOVAC  load/debug  capabilities. 
Data  reduction  could  be  accommodated  on  an  exclusive  basis  (system 
might  not  be  able  to  assemble  an  OFP  while  doing  data  reduction; 
oriented  for  very  limited  hardcopy  output). 


CPU  (11/60)  with  64K  Bytes,  Fit.  Pt. 

$ 

31. 3K 

Additional  192K  Bytes  to  fill  up  memory 

$ 

15. 0K 

RL-11  Disc  (For  DEC  backup) 

$ 

6.0K 

System  Industries  300M  Byte  Disc/Intf. 

$ 

24. 0K 

DEC  TJE16-EA  (9  Track  tape  drive) 

$ 

17.  IK 

DH-11  16  line  Multiplexer 

Terminals : 

$ 

6.6K 

a)  ADM  3A 

$ 

— 

b)  VT-100  (2) 

$ 

4.4K 

c)  DECWRITER  III 

$ 

3.8K 

d)  Diablo 

$ 

— 

Software:  (recommend  a  and  c  minimum) 

a)  RSX-11M,  for  4+ 

$ 

9.0K 

b)  BASIC  Plus  2 

$ 

2.5K 

c)  DATATRIEVE 

$ 

2.8K 

d)  IMSL 

$ 

1.3K 

e)  TOTAL  (or  other  DBMS)  (Sharable?) 

$ 

33. 0K 

This  second  section  covers  the  portable  components  to  build 
lab'  style  SOVAC  system  for  debug  and  loading  the  TC-2. 

a  'front 

PDP-11/23  system  (est.) 

$ 

10. 0K 

Dual  Floppy 

$ 

4.9K 

DUMCAD/MiniSovac  (est.) 

$ 

5.0K 

Tektronix  4014 

$ 

14. 5K 

PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


ENHANCED  SYSTEM 


DATE:  27  July  1979 


This  section  covers  the  enhancements  needed  to  upgrade  the  11/60 
system  to  provide  simulation  capabilities  in  addition  to  those  above. 
This  system  would  probably  be  able  to  support  full  data  reduction 
with  timesharing  for  program  development  running  concurrently  and 
an  assembly  running  in  'background*.  The  simulation  could  execute 
while  running  one  or  possibly  more  of  these  other  tasks  at  low 
priority. 


Second  Disc  Drive 

Line  Printer  (660LPM,  96char,  impact) 
Versatec  printer  plotter  (hardcopy  graphics) 
Second  Tape  Drive 
Miscellaneous  Interfaces 

Unique  TC-2  Interfaces 


$  12.0K 
$  25. 7K 
$  14. 0K 
$  11. 0K 
$  8.0K 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  -  SUPPORT  SOFTWARE 


DATE;  27  Julv  1979 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  -  TRAINING  REQUIREMENTS  DATE:  27  July  1979 
PROGRAMMER  TRAINING: 


What  percent  of  programmer  time  does  training  take?  10-20% 

Formal  or  OJT?  1/2  formal,  1/2  OJT 
How  many  curricula?  Numerous 
How  long?  Varies 

Training  agency:  Several  CSC,  NWC,  other  formal  and  informal 
Locations  of  training:  Local  and  TDY 
Training  adequacy:  Excellent 

What  kinds  of  morale  problems  do  you  experience?  How  do  you  handle  them? 

The  remote  location  of  China  Lake  limits  the  quantity  of  qualified  personnel 
available  to  fill  vacancies.  System  sponsors  and  users  do  not  make  requirements 
known,  so  future  tasks  are  uncertain. 


USER  TRAINING: 

Is  training  a  major  task?  Yes 

How  many  curricula?  Two  -  a)  New  OFP  Introduction,  b)  Fighter  Weapons  Course 
How  long  are  they?  a)  4  hours,  b)  2  days 
Training  agency:  a)  OC-ALC,  b)  Tucson,  162  TFG 
Locations  of  training:  a)  At  all  bases,  b)  Tucson,  AZ 

Background  required:  a)  General  pilots  and  maintenance  persdnnel,  b)  Advanced 

pilot  training 

Dropout  rate :  None 

Training  adequacy:  Engineering  team  also  produces  and  distributes  Video  Tape 

presentations  that  explain  changes  in  software  operation  that 
are  new.  Training  appears  adequate. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  - 

FLIGHT  TEST  REQUIREMENTS _ DATE:  27  July  1979 


SEQUENCE 

ORDNANCE 

1977 

PURPOSE 

FLT  # 

1 

NAV  (groom) 

2 

NAV 

3 

MK  76 

Weapons  Groom 

1* 

BDU-33 

5 

«! 

6 

NONE 

7 

BDU-33 

25Hz  vs.  20  Hz  accuracy 

8 

weapons 

9 

25Hz  vs.  20Hz  accuracy 

10 

It 

It 

11 

M 

12 

ft 

»t 

13 

It 

tl 

lU 

It 

It 

15 

»» 

II 

16 

ft 

tt 

17 

Nav 

18 

Nav 

19 

BDU-33 

Radar  Evaluation  Flight 

20 

BDU-33 

It 

21 

BDU-33 

also  Nav 

22 

Nav 

23  *NWC 

Vert.  vel.  corr. 

2k 

Nav 

25  *NWC 

Vert .  vel .  corr . 

26 

BDU-33 

Radar  Eval. 

27 

Nav  AF02 

28 

Nav  AF02 

29 

BDU-33 

CCIP  AF02 

30 

II 

•1 

31 

BDU-33 

ft 

32 

f* 

ft 

33 

Nav 

3** 

n 

35 

r» 

CCIF  -*  MER  Springs 

36 

f» 

II 

37 

»i 

II 

38  *NWC 

BDU-33 

BOC  -  V.A.  eval. 

39  *NWC 

ft 

Uo 

If 

CCIP  +  Springs 

1*1 

BDU-33 

Weap.  Eval. 

1*2  *NWC 

BDU-33 

CCIP  +  Visual  Atk. 

1*3  »NWC 

It 

CCIP  eval. 

1*L  *NWC 

II 

It 

1*5  »NWC 

ft 

V.A.  A  CCIP  eval. 

1*6  »NVC 

BDU-33 

CCIP  eval. 
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CONTINUATION  SHEET 


DATE:  27  July  1979 


1977 


SEQUENCE 

ORDNANCE 

PURPOSE 

FLT  #  1 

1*7  *NWC 

BDU-33 

CCIP  &  Visual  Atk. 

1*8 

Nav. 

1*9 

tl 

Weap .  Eval . 

50 

BDU-33 

MER  Springs  Eval. 

51 

It 

It 

52 

BDU-33 

Radar  Eval. 

53 

•1 

n 

51* 

BDU-33 

BOC  +  MER  Adapter  Eval. 

55  *NWC 

BDU-33 

BOC  &  BOC  Offset-loft 

56 

BDU-33 

also  Nav 

Fin  Adapter  Accuracy 

SEQUENCE 

ORDNANCE 

1978 

PURPOSE 

FLT#  I 

1 

BDU-33 

CCIP  &  Mer  Adapter  Eval. 

2  *NWC 

BDU-33 

HUD  Fail  &  E.O.  Bomb 

3  *NWC 

tt 

BOC  loft  Eval. 

1*  *NWC 

»» 

HUD  Fail  &  E.O.  Bomb 

5 

BDU-33 

V/A  &  Adapter  Eval. 

6  *NWC 

BDU-33 

Radar  Alt.  &  CCIP 

7  *NWC 

11 

Normal  Atk.  &  Steering  Error 

8 

Nav 

9  *N,  ORD 

MK  82HD  &  Rockets 

FLR  Auto  Reversion  (Nellis) 

10  *N,  ORD 

BDU-33  &  Rockets 

11 

11 

Nav 

12 

BDU-33 

Weapons  Eval. 

13 

!» 

Ground  Spacing 

ll* 

Nav 

15 

Nav 

16 

BDU-33 

MRI  Class  II 

17 

BDU-33 

Visual  Attack 

18 

n 

V/A  Offset  " 

19  *0RD 

LAU-68/l000-20mm/ 

Guns/Rkts/CBU 

20  *ORD 

1  CBU-30 

MK-82  flex  fuse 

Flex  Fuse 

21  *0RD 

MK-20,  6  MK-82 

MRI  Class  IV  ft  Class  III 

22  »0RD 

MK-81* 

Simple  lo 

23  *0RD 

BLU-27 

7-2-5 

2U  «0RD 

6  MK-82  SE 

MRI  Class  I  HT-l-U 

25  #0RD 

MK-82  SE 

"  #7-1-3 

26  *0RD 

MK-20 

MRI  Class  IV  #7-1-6 

27  *0RD 

MK-82 

L.D.  Option  #7-2-1 
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CONTINUATION  SHEET 


DATE:  27  July  1979 


SEQUENCE 
FLT  # 

28 

29 

30 

31 

32  *L 

33  *L 
3U  *L 

35 

36 

37 


ORDNANCE 

BDU-33 

BDU-33 

ft 

If 

BDU-33 

it 

it 


1978 

PURPOSE 


Visual,  Visual  Offset,  Hud  Update 

Nav 

Nav 

Weapons  Eval. 

Pave  Penny  6-1  OF?  Boresight  Acquisition 
"  p.p.  6-2,  Visual,  Visual  Offset 

ii 

Weap .  Eval . 

System  Eval. 


38 

BDU-33 

Pave  Penny  #6-2 

39  *L 

20mm  &  BDU-33 

Guns  w/Pave  Penny 

1*0  *L 

11 

Pave  Penny:  Offset  &  Guns 

1*1 

Nav 

1*2  *L 

20mm  &  BDU-33 

P.P. :B0C,  BOC  Offset  &  Guns 

!*3  *L 

it 

P.P. :  6-3  &  Guns 

UU  *L 

it 

P.P. :  &  Guns 

1*5  *L 

it 

P.P.:  Manual  Pdpple  &  Guns  #6-6 

1*6  *L 

it 

P.P, :  #6-2 

1*7*L 

it 

P.P. :  #6-3 

Total  Project  Flights  =  103 
Flights  Requiring  Instrumented  Range  =  l8 
Flights  Requiring  Ordnance  Crew  =  11 
Flights  Requiring  Laser  Designated  Target  =  11 


*fSfe«iu  +iu.*km  iMdm  »»■-•  ■ 


PREDICTIVE  SOFTWARE  COST  MODEL 

SOFTWARE  PACKAGE  MAINTENANCE  HISTORY  DATE:  27  July  1979 


DESCRIPTION  OF  NUMBERS  AND  TYPES  OF  MAINTENANCE  ACTIONS  PERFORMED  EACH  YEAR 
SINCE  PMRT 


Date 

Reason 

Gross  Number 
Instructions  A 

Net  Number  A 

Manhours 

Cost 

1/75 

Add  USAF 
Ballistics 

Unknown 

Unknown 

Unknown 

Unknown 

*1/76 

AF-1 

(See  attachment 
#10) 

Unknown 

Unknown 

Unknown 

Unknown 

2/76 

SCRUB  Unused 

Features 

Unknown 

Unknown 

Unknown 

Unknown 

8/77 

AF-2 

1592 

1480 

Note  1 

Note  1 

11/77 

AF-2 P-1 

Pave  Penny 

1630 

1409 

Note  1 

Note  1 

1/78 

AF-2 P-2 

Correct  Pave 
Penny 

158 

28 

Note  1 

Note  1 

*10/78 

Final  AF2.0 

248 

-297 

Note  1 

Note  1 

♦Indicates  Programs  Published 

Note  1:  For  the  AF-2  and  Pave  Penny  efforts,  14  manyears  of  effort  and  additional 
costs  of  $805,000  were  expended  during  FY'77  and  FY'78. 

Page  A-52  graphically  portrays  the  maintenance  history. 

Pages  A-53  through  A-55  list  the  changes  made  to  AF-2P-2. 
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PREDICTIVE  SOFTWARE  COST  MOO  EL 


CONTINUATION  SHEET 


DATE:  27  July  1979 


OFP  -  A7  AF-2 

MATH 

FLOW  REVISIONS 

1.  The  following  is 

a  list  of  changes 

CO 

the  Math  Flow  entitled  AF-2P  Rev.  2, 

01-01- 

78. 

Section 

Sheet 

Reference 

Change  Description 

Cover 

Page 

Delete  "AF-2P  Rev.  2"  and  insert 
"OFP  -  A7 ,  AF-2  16  Oct  1978” 

I 

8 

N414 

Set  LCAB  =  0;  delete  comment 

r 

19 

N1164 

Change  flow  director  to  19A  UTMFIX, 

19A 

Add  new  sheet  19A  in  accordance  with 
example  attached. 

i 

22 

N1230 

DI  1  Bit  13  vice  DI  1  Bit  8 

i 

22 

N1236 

Add  BARB  correction  in  accordance 
with  attached  example 

ii 

3 

AV2 

Add  AOA  calculations  in  accordance 
with  attached  example. 

ii 

12 

ARM25 

Sheet  13  or  14  vice  sheet  9 

ii 

12 

ARM20.6 

DI  3  Bit  7  vice  DI37 

ii 

12 

ARM21.1 

Set  Mode  =  K0008  vice  0001 

ii 

13 

ARM  28 

Add  "P . 12  ARM  6" 

ii 

18 

Item  600 

Change  to  read  "RRAD-K00AA  <  0 

ii 

18 

Block  after  Item 

600 

Change  to  read  "RRAD-K0AA-19E2  <  0 

ii 

18 

Block  after  Item 

600 

Add  note:  "FLR  MAX  RNG  =  52672'  , 

MIN  RNG  =  1344’ 

ii 

18 

12A-A 

Add  "P.19" 

ii 

19 

SP9.25 

3  BARO  (Vice  Z)  =  MAX  |  ZBARO.U  | 

ii 

19 

SP9.261 

Mode  =  Guns/Rockets  or  CCIP 

Vice  Guns/Rockets  only 

ii 

19 

SP31 

Add  "P.20" 

ii 

20 

SP23.6 

Add  five  point  smoothing  change  in 
accordance  with  attached  example 
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PREDICTIVE  SOFTWARE  COST  (MODEL 


CONTINUATION  SHEET _ DATE:  27  July  1979 


Section 

Sheet 

Reference 

Change  Description 

II 

21 

SP40.1 

Add  CCIP  Timing  Scrub  in  accord¬ 
ance  with  attached  example. 

II 

22 

RT  17  (2  places) 

Add  "P.23" 

II 

27 

RT  24 

Add  "P.23" 

II 

26 

25B 

Add  "P.22" 

II 

27 

WP31.3 

Mt  =  -Mr  vice  Mt'  =  Mr 

II 

27 

WP29 

Add  "P.28" 

II 

30 

HD6 

LAMAZ  vice  LAMEL 

LAMEL  vice  LAMAZ 

II 

30 

HD  7 

Check  signs  in  "LAMEFM" 

II 

30 

HD10 . 1 

Bit  6  vice  Bit  9;  2  places 

II 

30 

HD10.3B 

Brance  is  to  HD10.3C,  P.32 
vice  HD40 

II 

31 

HD25.71 

HD25.6 

Check  signs  of  a*  and  b* 

II 

32 

HD40 

Entry  point  is  HD10.3C  vice  HD40. 

HD40  is  on  sheet  33 

II 

33 

SETUM 

Branch  after  LAMERH  16°  test  should 
be  to  HIDESOL  vice  SETUM 

II 

35 

AR19 

Eliminate  tt  in  numerator  of  LAMARR 
calculation.  This  should  be 

ATANII,  not  tt. 

II 

46 

42A 

Add  BDU-33  Blast  Avoidance  Moding 
in  accordance  with  attached  example 

III 

4 

9A 

Set  Data  33  =  0,  in  Power-Up  in 
accordance  with  attached  example 

IV 

14 

ENT  30 

Change  UTM  processing  in  accordance 
with  attached  example 

IV 

14 

ENT  33 

Add  new  ENT  33  in  accordance  with 
attached  example 

IV 

15 

15  A, C,D 

Add  "P.16" 
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CONTINUATION  SHEET _ DATE:  27  July  1979 


Section 

Sheet 

Reference 

Change  Description 

IV 

15 

ER 

Add  "21B  P. 22" 

IV 

17 

19E 

Add  "P.20" 

IV 

28 

24A  "out" 

Add  "=99" 

IV 

28 

25  A&B 

Add  "P.29" 

IV 

25 

Data  32 

Add  comment  by  TTG  <  0  test  "com¬ 
pensate  for  next  day  target  times" 

IV 

25 

Data  33 

Add  Data  33  display  in  accordance 

with  attached  example 


During  1976-1978  the  USAF  team  developed  the  OFP  changes  of  the  AF-2  program 
while  Vought  developed  a  Pave  Penny  OFP.  The  two  efforts  were  later  combined 
into  a  single  AF-2  OFP.  Program  assemblies  were  all  performed  by  Vought  since 
the  USAF  Assembler  was  not  available  until  1978.  The  Memory  Scrub  of  February 
1976  did  not  maintain  stringent  configuration  control  and  was  the  cause  of 
corrections  as  late  as  January  1978.  To  ensure  better  configuration  control 
in  later  assemblies,  the  USAF  team  developed  a  "Compare"  program  to  list  dif¬ 
ferences  between  assemblies.  Currently  (Jun  1979)  the  USAF  team  assembles  on 
either  the  PDP  11/45  or  Honeywell  Sigma  V  at  China  Lake.  Handloads  relate 
directly  to  source  code  editor  listings  and  "Compare"  is  used  to  extract  the 
handload  from  the  final  assembly  to  ensure  configuration  control. 
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PREDICTIVE  SOFTWARE  COST  MODEL 
SOFTWARE  PACKAGE  MAINTENANCE  COST  HISTORY 


DATE:  27  July  1979 


Provide  yearly  cost  of  maintaining  cackage,  break  down  to  cost  per  change 
if  possible. 


FIGURES  IN  ($K) 

NWC  Contracts  FY  77  FI 

I.  MANAGEMENT  &  ENGINEERING 

a)  Admin.  &  Budget  30 

b)  Materials  &  Supplies  20 

c)  Travel  18 

d)  Contracted  Documentation  10 

e)  Contracted  Config.  Mgt.  9 

f)  NWC  Engineering  Labor.  60 

II.  SIMULATION  &  LAB  FACILITIES 

a)  Labor  110 

b)  Contracted  Maintenance  40 

c)  Equipment  via  NWC  30 

d)  Computer  Use  Charges  10 

III.  FLIGHT  TESTING 

a)  Range  Charges  40 

b)  Data  Reduction  40 

c)  A/C  Modification/  8 

Instrumentation  _ 

TOTAL  425  2 

$K/MAN  YEAR  60 

Cost  per  instruction  for  AF-2  and  Pave  Penny 

14  Man  Years  $840,000 

Additional  Costs  =  805,000 

$1,645,000 

Cost/Instruction  «  1,645,000/3628  *  $453/Instruction 


PROJECTED 


FY  77 

FY  78 

FY  79 

30 

31 

32 

20 

18 

20 

18 

20 

20 

10 

0 

9 

9 

7 

12 

60 

34 

36 

110 

60 

43 

40 

55 

60 

30 

24 

25 

10 

12 

14 

40 

46 

52 

40 

61 

62 

8 

12 

15 

425 

380 

400 

60 

62 
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HISTORICAL  DATA  SOURCES 

Data  Base  Name 
Location 
Contact  Person 
Phone  Number 
General  Contents 


_ _ _  DATE:  27  July  1979 

A-7D  Operational  Flight  Program 
OC-ALC/MMECZA,  Code  91,  China  Lake,  CA 
Mark  E.  Jacobson 
Commercial  (714)  939-5575 

Dollars  expended  by  Fiscal  Year  buying  services  from 
NWC.  Broken  down  into  broad,  general  categories. 


Period  Covered  FY  77  through  FY  79 

General  assessment  of  data  quality  -  very  little  detail 


PREDICTIVE  SOFTWARE  COST  MODEL 


RECOMMENDATIONS  RE  SOFTWARE  SUPPORT  COST  PREDICTING _ DATE:  27  July  1979 

RESPONDENT:  Mark  Jacobson 

One  of  the  first  tasks  would  be  to  discover  who  was  (hopefully  still  is)  the 
prime  contractor  and  the  contractor  responsible  for  the  software.  Contractor 
reputation  would  give  an  indication  of  experience  and  with  some  investigation 
the  methods  used  to  develop  the  package  would  be  visible.  The  contractor  also 
would  be  important  to  provide  the  maintenance  team  with  sufficient  technical  data 
to  allow  maintenance  of  the  software.  It  would  be  especially  important  to  review 
requirements  and  design  documents  to  get  the  feeling  for  the  design  process, 
design  decisions  and  structure  of  the  program.  The  contractor's  facilities  may 
also  provide  information  about  the  facilities  needed  (or  additional  facilities 
needed) . 

The  second  task  would  be  to  discover  the  Using  Command's  intended  uses  of 
the  system  and  if  any  substantial  system  enhances  are  foreseen.  This  would  give 
an  indication  of  areas  likely  to  change  in  the  program  and  also  provide  an  input 
for  the  size  and  experience  level  of  the  goverrment  team  necessary.  It  would  be 
equally  important  to  establish  the  maintenance  office  responsibilities  during  the 
life  cycle  of  the  system.  Often,  the  maintenance  office  is  tasked  with  R+D  type 
taskings  because  they  have  access  to  the  system  and  system  testing  facilities. 

If  an  R+D  effort  appears  likely,  then  the  proper  personnel  for  this  type  of  effort 
must  be  included  in  the  maintenance  team. 

The  third  task  would  be  to  develop  an  .nderstanding  of  the  system  and  the 
data  chat  is  input  to  and  ouput  from  the  system.  If  this  systems  engineering 
analysis  appears  to  correlate  with  the  design  of  the  system,  programmer  and 
engineering  responsibilities  will  be  better  defined.  Also  at  this  time,  growth 
possibilities  for  the  system  could  be  analyzed  and  used  to  again  determine  areas 
of  the  system  that  are  likely  to  change. 

The  fourth  task  would  be  to  assess  the  availability  of  existing  testing 
facilities,  including  the  system  itself  and  test  support  facilities.  If  this  is 
an  aircraft  system,  then  aircraft  availability,  range,  maintenance  personnel  and 
equipment  are  all  importand  and  I  would  make  every  attempt  to  extract  the  software 
maintenance  program  from  aircraft  operations /maintenance.  This  would  require 
the  services  of  a  testing  group  and  the  contents  of  this  group  would  be  most 
important  since  a  good  testing  group  can  help  in  the  proof  of  the  software  and 
also  answer  questions  on  tactical  applicability  of  the  system. 

If  local  computer  facilities  are  not  sufficient  to  perform  the  software 
services  needed  during  the  maintenance  of  the  system,  procurement  of  the  necessary 
computing  power  will  be  necessary.  I  would  approach  this,  using  the  background 
obtained  earlier,  and  most  likely  would  choose  computing  power  different  from 
the  contractor.  This  would  force  the  maintenance  group  to  develop  their  own 
facilities  and  thereby  promote  in-depth  understanding  of  the  system.  This  also 
has  the  advantage  of  having  two  different  approaches  to  the  maintenance  problem  - 
the  contractor  may  resolve  certain  issues,  while  the  government  team  may  discover 
other  areas  of  concern. 
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CONTINUATION  SHEET _ DATE:  27  July  1979 

Of  overall  importance  would  be  the  management  support  for  the  maintenance 
effort  and  the  personnel  involved  in  the  maintenance  effort.  The  management 
support  is  needed  to  allow  the  maintenance  manager  to  develop  long-term 
personnel  plans  for  the  members  of  the  maintenance  team.  These  plans  could 
then  be  used  as  a  departure  point  for  training,  work  assignments,  promotions, 
etc.  If  the  program  was  large  enough,  an  Organizational  Development  specialist 
should  be  included  to  ensure  that  the  technical  personnel  involved  in  the 
maintenance  effort  understand  their  responsibilities  and  opportunities,  and 
also  so  that  management  understands  the  personnel  problems  that  may  prove  to  be  a 
very  large  factor  in  future  efforts. 

Of  general  importance  would  be  to  make  use  of  all  previously-developed 
tools  and  good  software  maintenance  practices.  Support  software  that  can  be 
procured  is  usually  preferable  to  in-house  developed  software  because  of  the 
unpredictable  nature  of  in-house  developed  software  and  the  long-term  maintenance 
of  such  support  software.  Also,  design  documents  and  other  documentation  should 
be  procured  from  the  contractor  along  with  any  tools  to  keep  these  documents 
current . 
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PREDICTIVE  SOFTWARE  COST  MODEL 
FIELD  EVALUATION  REPORT 


GENERAL  SOFTWARE  PACKAGE  DESCRIPTION _ DATE:  28  Sept  1979 


ALC:  SM 

WEAPON  SYSTEM:  FB-111A 

SOFTWARE  PACKAGE:  General  Navigation  Computer /Weapons  Delivery  Computer 

PERSONNEL  CONTACTE  j.  Patterson,  MMECP 


Lynn  Bassett,  MMECP 


SOFTWARE  PACKAGE  CHARACTERISTICS:  (two  packages  -  see  page  B— 2) 

SIZE:  16K  each  for  General  Navigation  Computer  (GNC)  and  Weapons  Delivery 
Computer  (WDC) . 

LANGUAGE:  Assembly 

application:  Navigation,  Weapons  Delivery 

COMPLEXITY:  High 

YEAR  DEVELOPED.  1968 

developer:  Autonetics 

COMMENTS  Minimal  attention  given  to  software  reliability  and  maintainability. 
See  rating  of  quality  attributes  on  page  B-3. 

HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS:  (two  computers) 

MANUFACTURER:  IBM 

MODEL  NUMBER/DESIGNATOR:  CP 2 
WORD  SIZE:  16-bit 
MEMORY  SIZE:  16K  each 

MEMORY  FILL:  200  empty  words  each  (98.3%) 

WEAPON  SYSTEM  USE: 

NUMBER  OF  USERS:  70 

LOCATIONS  OF  USERS:  Plattsburgh  AFB ,  N.Y.,  Pease  AFB ,  N.H. 

FREQUENCY  OF  USE:  Daily 

INTERVIEWER(S):  R.  B.  Waina,  A.  P.  Bangs 
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PREDICTIVE  SOFTWARE  COST  MODEL 

CONTINUATION  SHEET-  Quality  Attributes _ DATE:  28  Sept  1979 


Rate  the  Package  on  the  following  Quality 

attributes : 

Accessibility:  0 

Instrumentation:  4 

Accountability:  N/R 

Interoperability:  0 

Access  Audit:  N/R 

Integrity:  10 

Access  Control:  N/R 

Legibility:  5 

Accuracy:  9 

Maintainability:  8 

Augmentability :  6 

Modifiability:  8 

Clarity:  A 

Modularity:  4 

Communicativeness :  8 

Operability:  N/A 

Communications,  Commonality:  N/A 

Performance:  10 

Completeness:  9 

Portability:  0 

Conciseness:  9 

Reliability:  9 

Cons istency : 

Robustness:  8 

Internal  Consistency:  7 

Reusability:  0 

External  Consistency:  8 

Self containedness :  10 

Correctness:  10 

Selfdescriptiveness :  5 

Data  Commonality:  N/A 

Simplicity:  3 

Efficiency:  10 

Structuredness:  7 

Execution  Efficiency:  10 

Storage  Efficiency:  10 

Testability:  8 

Error  Tolerance:  9 

Traceability:  8 

Expandability:  6 

Training:  N/A 

Generality:  0 

Understandability :  4 

Human  Engineering:  9 

Usability  (as-is  utility):  9 

Independence:  0 

Device:  0 

Software  System:  0 
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MAI NTENANCE  AGENCY  PERSONNEL _ DATE:  28  Sept  1979 


TOTAL  PACKAGES  MAINTAINED  (NUMBER  &  TYPE): 


7  -  one  OFP  for  each  of  the  two  computers  (GNC  and  WDC)  for  each  of  the  three 
aircraft,  (F-111D,  F-111F,  FB-111A),  plus  one  OFP  for  the  NCU  computer  program 
for  all  three  aircraft.  Additionally,  much  simulation  and  support  software  is 
maintained,  and  numerous  special  projects  are  carried  out. 


PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  WORK  DISTRIBUTION _ DATE:  28  Sept  1979 


DESCRIPTION  OF  WORK  PACKAGE  D'^TRIBUTION,  INCLUDING  RESPONSIBILITIES  AND  DEGREE  OF 
SPECIALIZATION  OF  AF/CS/CONTR  PERSONNEL(MMECP) 

NUMBER  OF  PERSONNEL 

FUNCTION 

AF  CS 

CONTR 

Management /Secretary 

4 

3 

FB-111A  S/W  Engineering 

1 

5 

F-111D  S/W  Engineering 

1 

5 

F-lllF/Pavetauk  S/W 
Engineering 

1 

5 

Mission  Programs 

1  3 

F-lll  A/E  Acquisition 
Support 

2 

1 

F-lll  AISF  Enhancements 
and  S/W  Support 

15 

F-lll  OFP  Mk  II  V  i  V 

3 

3 

Flight  Test  Support 

5 

S/W  Configuration 
Management 

4 

TSU 

5 

Special  Projects 

2  5 

10 

Major  AISF  Upgrades 

[5-10  off-premise] 

4  19 
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CONTINUATION  SHEET  -  WORK  DISTRIBUTION _ DATE:  28  Sept  1979 

Manhours  for  FY’77  through  FY'79  are  distributed  as  follows: 


Function 

FY'77 

FY'78 

FY'79 

FB-111A 

18,041 

15,069 

9,809 

F-111F 

16,926 

8,877 

20,243 

F-111D 

13,880 

19,376 

14,373 

Other  F-lll 

6,391 

3,288 

6,467 

Support  Software 

23,790 

29,776 

21,094 

Special  Projects 

28,982 

35,224 

33,548 

Leave/Holiday 

19,904 

23,580 

24,597 

Total 


127,914 


135,190 


129,131 
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MAINTENANCE  AGENCY  -  COST  ACCOUNTING  SYSTEM _ DATE:  28  Sept  1979 


SMALC  uses  a  manhour  accounting  system  which  logs  manhours  by  project.  For  each 
specific  aircraft  type  block  change,  manhours  are  accounted  for  by  five  functions: 
management,  definition,  development,  documentation  and  test.  There  is  also  a 
category  for  OfP  Group  Management.  Beyond  that,  individual  functions  (e.g., 
configuration  management)  and  projects  are  tracked. 
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MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES _ DATE:  28  Sept  1979 

SUPPORT  PHILOSOPHY: 

AFLC  needs  to  utilize  its  resources  effectively  and  efficiently  in  maintaining  and 
updating  OFP's.  A  system  entitled  F-lli  OFP  Change  and  Control  has  been  implemented 
in  support  of  the  F-lll  aircraft.  OFP's  provide  aircraft  systems  with  tremendous 
flexibility »  provided  changes  can  be  made  to  them  in  a  timely  manner.  New  aircraft 
capabilities,  enhancements  and  improvements  can  be  achieved  through  changes  to  OFP's. 
For  example,  capabilities  and  improvements  added  to  the  F-lll  through  OFP  changes 
include  SRAM  alternate  launch,  moving  target  detect,  expanded  offset  aimpoints, 
improved  beacon  bombing,  enhanced  fixtaking,  expanded  steerpoints,  updated 
ballistics,  and  added  avionics  diagnostics.  In  addition,  many  modes  have  been 
improved,  changed  or  deleted;  navigation  and  bombing  performance  has  been  improved 
and  numerous  latent  deficiencies  corrected.  This  has  been  accomplished  through 
some  177  OFP  changes  over  a  3-year  period. 

The  concept  developed  which  permits  OFP  change  activity  of  this  order  is  the 
OFP  Block  Change.  A  block  change  is  a  collection  of  OFP  changes  (i.e.,  software 
changes  only — no  hardware  impacts)  which  are  concurrently  processed  and  integrated 
(cont.  on  p.  B-  9.) 

CHANGE  CONTROL  METHODS: 

FORMAL  OR  INFORMAL:  Very  formal 


CHANGE  REVIEW  PROCESS:  See  pages  B-10  through  B-17 


CONFIGURATION  IDENTIFICATION  METHODS:  See  page  B-15  ff 


CONFIGURATION  CHANGE  CONTROL  METHODS:  See  page  B-15  ff 


CONFIGURATION  STATUS  ACCOUNTING  METHODS:  Within  the  change  process  a  baseline 
tape  is  generated.  Individual  changes  are  then  keyed  in  by  number.  See 
description  of  the  "dot-files,"  pages  g-21/22. 

SOFTWARE  LIBRARY  CONTROL  PROCEDURES: 
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CONTINUATION  SHEET-  SUPPORT  PHILOSOPHY _ DATE:  ?g  sPnr  iq 

into  the  baseline  program  over  some  period  of  time.  Since  changes  to  OFP's  are 
viewed  as  a  continuing  task  over  the  life  cycle  of  the  aircraft  system,  the  block 
change  becomes  a  cyclic  process.  Efficiency  is  derived  through  a  level  of  effort 
staffing  and  collective  OFP  change  processing.  Responsiveness  is  derived  by 
keeping  the  cycle  time  to  limits  acceptable  to  the  user.  Obvious  tradeoffs  are 
level  of  effort  staffing,  number  of  changes  in  a  block  change  and  cycle  time. 

For  long-term  efficiency  the  level  of  effort  and  cycle  time  are  fixed  and  the 
parameter  that  varies  from  block  change  to  block  change  is  the  number  of  OFP 
changes.  This,  of  course,  varies  as  a  function  of  the  priorities  of  change 
candidates  and  the  magnitude  and  complexity  of  each.  Flexibility  is  achieved 
in  several  ways.  First,  emergency  changes  can  be  expedited  by  processing  on  an 
individual  basis.  Depending  on  change  magnitude,  complexity  and  risk,  it  is 
possible  to  process  these  changes  in  a  matter  of  weeks.  Further,  depending  on 
priority  and  complexity,  changes  can  be  added  or  deleted  from  the  block  change 
until  late  in  the  change  cycle,  i.e.,  until  configuration  freeze.  Finally,* 
configuration  control  procedures  have  been  set  up  in  accordance  with  AFR  800-14 
to  process  Computer  Program  Change  Proposals  (CPCP's)  outside  of  the  hardware 
configuration  change  process.  A  CPCP  is  the  vehicle  used  for  identification  and 
approval  of  the  OFP  Block  Change  and  attendant  weapon  system  impacts.  These 
procedures,  in  addition  to  adding  flexibility,  also  greatly  improve  the  responsive¬ 
ness  of  the  change  system.  Of  course,  with  flexibility  of  this  nature,  strict 
control  and  complete  documentation  is  essential  for  configuration  management. 
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CONTINUATION  SHEET  -  CHANGE  REVIEW  PROCESS  AND  CONTROL  METHODS  PATE:  28  Sept  1979 
OFP  BLOCK  CHANGE  CYCLE: 

Figure  3  depicts  the  development  cycle  used  for  F-lll  OFP  Block  Changes  and  is 
similiar  to  the  standard  software  development  cycle.  It  includes  the  major  phases 
of  analysis,  feasibility,  design,  development,  test,  documentation  and  delivery. 

As  shown  in  Figure  3,  each  phase  starts  and  finishes  with  well  defined  milestones. 

The  cycle  is  periodic  with  a  3-month  overlap  and  produces  updated  OFP's  for  the 
user  on  an  annual  basis.  Tradeoffs  which  dictated  cycle  time  were  F-lll  change 
activity,  required  user  response,  and  available  support  resources.  However, 
other  practical  considerations  which  limit  the  minimum  cycle  time  are  mission 
simulator  updates,  availability  of  test  aircraft,  crew  training,  and  documentation 
update. 

Referring  to  Figure  B-3  the  change  cycle  starts  with  a  requirements  review.  This 
is  a  user,  system  manager,  engineering  review  where  problems  and  change  require¬ 
ments  which  have  accumulated  over  the  past  year  are  reviewed  and  prioritized . 

The  Operational  Software  Requirements  Document  (OSRD)  is  updated  and  the 
feasibility  study  defined. 


Figure  P-3.  Operational  Flight  Program  Change  Cycle 
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CONTINUATION  SHEET-  CHANGE  REVIEW  PROCESS  AND  CONTROL  METHODS 


DATE:  28  Sept.  1979 


The  Feasibility  Study  Phase  is  conducted  by  engineering  in  accordance  with  user 
priority.  It  primarily  consists  of:  determining  the  update  task  for  each  change; 
scoping  the  resource  requirements;  investigating  change  impacts  on  other  parts  of 
the  weapon  system  and  support  equipment;  looking  at  computer  memory  and  timing 
impacts;  investigating  integration  problems;  and  determining  if  each  change 
requirement  is  technically  feasible  and  will  actually  provide  the  user  with 
what  is  expected.  The  results  of  the  feasibility  study  are  then  presented  at  an 
OFP  Block  Change  Definition  meeting  attended  by  the  user,  the  system  manager  and 
engineering.  Based  on  the  results  of  the  feasibility  study,  an  OFP  Block  Change 
Definition  is  established  and  agreed  to.  Constraints  adhered  to  are:  the  block 
change  contains  only  change  candidates  which  do  not  impact  hardware;  the  changes 
can  be  worked  within  existing  resources;  and  the  cycle  time  is  maintained.  Changes 
which  do  not  meet  these  constraints  are  referred  to  the  system  manager  for 
processing  in  accordance  with  hardware  procedures.  The  main  output  of  the  feasi¬ 
bility  study  is  the  OFP  Block  Change  Requirements  Document. 

The  Preliminary  Design  Phase  consists  of:  translating  requirements  into  engineer¬ 
ing  terms;  updating  flow  charts  and  logic  layouts,  defining  mechanization,  inter¬ 
face,  scaling,  and  timing  requirements;  developing  change  narratives;  determining 
the  scope  of  impact  to  documentation,  technical  orders,  mission  simulator  and  other 
weapon  system  software;  and  preparing  and  submitting  the  Computer  Program  Change 
Proposal  (CPCP) . 

The  Initial  Development  Phase  consists  of:  establishing  the  development  baseline 
block  change  programs;  firming  up  mechanization;  programming  and  testing  prelim¬ 
inary  code;  and  establishing  documentation  files. 

The  Development  Phase  begins  with  the  approval  of  the  CPCP  by  both  the  user  and 
system  manager.  The  development  phase  consist  of:  finalizing  and  testing  program 
code  for  each  OFP  change;  developing  engineering  tapes,  addendums,  and  documenta¬ 
tion;  developing  change  descriptions;  developing  the  project  test  plan;  developing 
flight  test,  data  reduction  and  instrumentation  test  requirements;  preparing  test 
procedures;  and  providing  preliminary  data  for  mission  simulator  updates. 

The  Integration  and  Implementation  Phase  begins  with  the  laboratory  integration  of 
all  OFP  Block  Change  requirements.  A  user /engineering  meeting  is  convened  to  discuss 
engineering  and  user  flight  test  policy  and  to  conduct  a  laboratory  demonstration 
of  each  OFP  change.  Final  reassembly  of  all  approved  OFP  changes  with  the  develop¬ 
ment  baseline  program  is  accomplished  and  the  master  engineering  OFP  tape  produced. 
Formal  verification  testing  and  evaluation  by  the  development  engineering  group  is 
completed.  Engineering  source  data  for  technical  orders  and  engineering  documenta¬ 
tion  is  developed.  Formal  test  and  evaluation  procedures  are  finalized.  The  mission 
and  weapon  control  programs  are  produced.  Laboratory  test  and  flight  test  aircraft 
configurations  are  established  to  include  aircraft  computer  data  pumps  and  data 
reduction  software.  These  steps  are  in  preparation  for  formal  test  and  evaluation. 

The  Formal  Test  and  Evaluation  Phase  starts  with  the  turnover  of  the  master  engineer¬ 
ing  OFP  tape  to  a  separate  engineering  group  for  test  and  evaluation.  Formal 
testing  consists  of  a  three  phase  laboratory  test,  instrumented  engineering  flight 
test,  and  user  Operational  Test  and  Evaluation  (OTS.E)  .  Phase  I  of  laboratory 
testing  is  a  dynamic  functional  test  of  all  OFP  modes.  When  completed,  the  master 
engineering  OFP  tape  is  cleared  for  engineering  flight  test.  Initial  engineering 
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CONTINUATION  SHEET  -  CHANGE  REVIEW  PROCESS  AND  control  MF-mnns  DATE:  28  Sept  1979 

flight  test  looks  at  overall  air  suitability  and  clears  the  master  engineering 
OFP  tape  for  user  OT&E.  Once  cleared,  OT&E  and  final  engineering  flight  test  are 
conducted  concurrently.  Phase  II  and  III  of  the  formal  laboratory  test  are  also 
run  concurrently.  Phase  II  is  a  quantitative  test  of  performance,  a  look  at 
performance  envelopes  and  an  inspection  of  code  and  baseline  documents.  Phase  III 
is  the  retesting  of  modifications  resulting  from  problems  discovered  during  test. 
Part  way  through  formal  testing  a  meeting  between  the  user  and  engineering  is 
convened  to  review  test  results  and  to  establish  an  OFP  Block  Change  configuration 
freeze.  Mandatory  corrections  to  program  discrepancies  are  defined,  implemented 
and  retested;  trivial  anomalies  are  accepted;  and  in  the  event  a  change  cannot 
be  accomplished,  its  coding  is  removed.  Also,  during  this  phase  technical  order 
source  data  is  verified  and  validated  by  the  user,  engineering  and  the  system 
manager.  Source  inputs  for  the  mission  simulator  updates  are  finalized  and 
delivered.  At  the  completion  of  the  formal  test  phase,  the  master  OFP  engineering 
addendum  tape,  incorporating  all  corrections  found  during  test,  is  merged  with  the 
master  engineering  OFP  tape  to'  produce  the  engineering  OFP  release  tape  and  the 
final  OFP  Block  Change  documentation. 

During  the  Documentation  Phase  the  engineering  OFP  release  tape  is  converted  into 
a  production  version  and  tested.  All  engineering  documentation  is  finalized;  the 
technical  order  masters  are  prepared  and  made  ready  for  reproduction.  The 
evaluation  of  test  results  is  completed  and  the  final  test  report  is  issued. 

During  the  Publication  and  Preparation  for  Release  Phase  the  production  OFP  tapes 
are  duplicated;  engineering  documentation  and  technical  orders  are  published;  the 
final  OFP  Block  Change  Report  is  issued;  and  the  new  OFPs  and  associated  technical 
orders  are  concurrently  released  to  the  user  under  a  TCTO. 

OFP  BLOCK  CHANGE  PROCESS  AND  RESOURCE  UTILIZATION; 

Fig.ireB-4  depicts  the  F-lll  OFP  Block  change  process.  It  illustrates  several 
significant  points:  process  flow;  resource  utilization;  and  major  input/output 
products.  The  OFP  Block  Change  process  from  start  to  finish  is  highly  technical, 
and  primarily  involves  engineering  and  engineering  resources.  However,  system 
management,  technical  publications  and  user  participation  are  essential.  The 
system  manager  has  complete  responsibility  for  the  control,  coordination  and 
integration  of  OFP  changes  into  the  overall  integrated  logistics  management  support 
system  and  participates  to  that  extent.  The  user  is  intimately  involved  during 
feasibility  and  change  definition  to  establish  requirements  and  priorities,  and  to 
assure  that  requirements  are  properly  interpreted.  Further,  the  user  actively 
participates  during  the  integration  and  test  phases  so  that  performance  can  be 
verified  and  acceptance  granted  prior  to  configuration  freeze  and  OFP  release. 

The  user's  primary  participation  during  these  phases  is  in  the  laboratory  veri¬ 
fication.  During  the  documentation,  publication  and  preparation  for  release 
phases,  the  system  manager  and  technical  publications  are  extensively  involved 
in  the  preparation  and  publication  of  technical  orders,  the  duplication  of  OFP 
tapes  and  the  preparation  of  the  TCTO  for  release.  Engineering  is  responsible 
for  the  technical  management,  planning  and  direction  of  the  complete  OFP  change 
program  and  is  also  responsible  for  the  development  and  implementation  of  all  OFP 
changes.  Therefore,  engineering  is  actively  involved  in  all  phases  both  from  the 
program  management  and  technical  detail  aspects. 

As  noted  in  Figure  B-4  the  engineering  resource  utilized  throughout  the  OFP  change 
process  is  the  Avionics  Integration  Support  Facility  (AISF).  Figure  B-5  depicts 
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the  F— 111  AISF  which  consists  of  an  avionics  integration  area,  subsystem  test  area, 
OFP  dynamic  simulation  area,  computer  support  area  and  instrumented  flight  test 
aircraft.  The  integration,  simulation  and  computer  support  areas  are  used 
extensively  throughout  the  change  process  while  the  flight  test  capability  is 
extensively  used  during  the  test  and  evaluation  phase. 

The  integration  area,  which  contains  avionics  integraton  test  equipment  (ITE), 
is  used  to  integrate  the  OFPs  with  the  avionics  system.  It  further  is  used  to 
recreate  flight  problems;  check  hardware /software  interfaces;  evaluate  timing, 
stabilization  and  synchronization;  and  to  conduct  final  OFP/avionics  system 
compatibility  tests.  On-line  OFP  change  capability  is  available  in  this  area 
which  enables  efficient  and  expedient  implementation  of  trial  solutions. 


FigureB-4.  OFP  Change  Process 
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The  F-lll  OFP  dynamic  simulation  area  provides  a  unique  capability  to 
quantitatively  analyze,  develop,  test  and  evaluate  OFP's  and  OFP  changes  under 
realistic  and  repeatable  conditions.  The  systems  are  hybrid  simulators  which 
retain  the  avionics  computers  with  their  resident  OFP's  and  simulate  the  world 
as  seen  by  these  computers  in  actual  flight.  Complete  visibility  is  gained 
into  the  innermost  parts  of  the  OFP's  through  data  monitoring  and  acquisition 
systems  which  provide  for  full  real-time  traces  of  OFP  execution.  Each  simu¬ 
lation  system  is  made  up  of  three  Harris  Corporation  6024/VM  mini-computer 
systems,  an  aircraft  cockpit  mock-up,  special  interface  devices  and  a 
simulation  software  package. 

The  computer  support  area  satisfies  all  computer  support  requirements  associated 
with  maintaining  and  updating  OFP's.  These  requirements  include  reassembly;  data 
reduction  and  analysis;  documentation  generation,  maintenance  and  storage; 
maintenance  of  support  software;  specialized  programs  and  programming ;  and  auto¬ 
mated  configuration  control.  The  reassembly  and  automated  documentation  generation 
o^°5eSS  is  shown  in  Figure  B-6.  The  computer  support  system  includes  two  Interdata 
8/32  mini-computer  systems,  a  PDP  11/40  mini-computer  system  and  a  remote  terminal 
to  an  IBM  360/65  complex. 

The  flight  test  capability  includes  El  coded  F-lll  aircraft  equipped  with  special 
instrumentation  packages  designed  specifically  for  monitoring  and  recording  OFP 
flight  performance.  Flights  are  conducted  to  test  overall  OFP  performance  and  air 
suitability;  analyze  change  and  problem  areas;  test  specific  modes  and  functions; 
and  to  obtain  engineering  data  to  define  and  verify  system  performance. 
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Figure  B-6.  OFP  Tape  and  Automated  Documentation  Generation 


The  AlSF  technical  staff  consists  of  engineers,  programmers  and  technicians.  They 
encompass  a  spectrum  of  expertise  on  the  aircraft  system,  avionics,  computers, 
operational  software,  support  software,  bomb  navigation,  scientific  programming, 
instrumentation,  data  reduction,  systems  analysis,  configuration  management,  and 
equipment  and  software  maintenance. 

OFP  TAPE  AND  AUTOMATED  DOCUMENTATION  GENERATION: 

The  key  to  efficiently  making  OFP  changes  and  controlling  configuration  lies  in 
an  automated  process  for  generating  OFP's  and  all  associated  documentation. 

Figure  B-6111ustrates  the  F-lll  OFP  Tape  and  Automated  Documentation  Generation 
System  which  ultimately  will  satisfy  this  goal.  To  date  the  process  performs 
the  reassembly,  documentation/  addendum  generation,  merge,  and  production  program 
conversions.  The  output  products  are  engineering  and  production  tapes,  program 
listings,  computer  files,  and  documentation. 

The  process  starts  with  the  reassembly  of  the  last  released  OFP  to  incorporate  the 
Master  Addendum  changes  along  with  subsequent  changes  to  optimize  program  coding 
for  memory  and  timing  benefits.  The  output  consists  of  the  development  baseline 
OFP.  Inputs  to  the  Documentation  Program  during  development  and  integration 
include  engineering  development  data,  reassembly  code  and  the  specific  machine 
code  for  the  preparation  of  engineering  addendum  tapes.  The  documentation  and 
files  generated  from  the  Documentation  Program  include:  OFP  change  descriptions 
and  requirements,  change  objectives,  status,  mechanization,  assembly  code, 
machine  code  (for  key-ins  and  addendums);  flight  test,  instrumentation  and  data 
reduction  requirements;  test  procedures,  technical  order  impacts  and  historical 
data.  This  information  is  continuously  updated  during  the  OFP  Block  Change  cycle. 
Prior  to  formal  test  and  evaluation  the  final  development  addendum  is  reassembled 
with  the  development  baseline  to  produce  the  master  reassembled  engineering  base¬ 
line.  The  final  OFP  Block  Change  configuration  or  engineering  release  is  defined 
by  the  reassembled  engineering  baseline  and  the  Master  Addendum.  Formal  testing 
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is  accomplished  only  with  the  computers  loaded  with  the  baseline  OFP  and  an 
approved  or  Master  Addendum  thereby  assuring  a  completely  documented  and  controlled 
configuration.  Current  plans  are  to  enhance  the  system  such  that  all  configuration 
control  documentation  listed  in  Figure  B-7  can  be  produced  using  this  system. 

OFP  CONFIGURATION  CONTROL  DOCUMENTS: 


The  OFP  Change  and  Control  System  provides  for  extreme  flexibility  and  therefore, 
strict  control  is  essential  if  OFP  configuration  is  to  be  maintained.  The  manage¬ 
ment  control  aspects  associated  with  OFP  changes,  and  the  change  process,  have 
been  described;  however,  essential  to  configuration  control  and  management  is  good 
documentation.  Since  software  is  intangible  (can't  see  or  touch  it),  the  documen¬ 
tation  must  be  very  thorough  in  describing  its  functional  and  performance  charac¬ 
teristics.  Equally  as  important  is  the  requirement  to  have  total  visibility  as 
to  how  these  characteristics  were  derived.  Without  documentation  that  does  these 
things,  the  on-going  change  process  would  eventually  collapse.  Figure  7  illus¬ 
trates  what  is  considered  a  complete  set  of  OFP  configuration  control  documents 
and  where  in  the  F-lll  OFP  change  cycle  these  documents  are  completed  and 
available.  The  list  is  confined  to  the  end  item  OFP  and  is  not  intended  to 
include  documentation  on  supporting  resources,  support  software  or  other  portions 
of  the  weapon  system  impacted  by  the  OFP  changes.  A  similar  set  of  documents  is 
obviously  required  for  these  areas.  An  exception  to  this  is  in  the  formal  test 
and  evaluation  process,  As  noted  in  Figure  B-7,  documents  defining  the  test  config-i 
uration  of  the  laboratory,  test  aircraft,  and  mission  and  weapon  control  programs 
are  required.  If  and  when  other  test  resources  are  used  in  formal  testing,  their 
configuration  should  also  be  documented  and  become  a  part  of  the  OFP  configuration 
control  documents.  As  shown  in  Figure  B-7,  the  physical  documentation  includes 
both  automated  and  manually  prepared  documents  as  well  as  computer  stored  programs. 

Current  change  requirements  and  problems  are  documented  in  the  Operational  Software 
Requirements  Document  (OSRD) .  A  historical  list  of  all  requirements  and  problems, 
including  those  listed  in  the  OSRD,  is  maintained  in  the  Master  Software  Require¬ 
ments  Document  (MSRD) .  All  OFP  source  programs  and  programs  generated  after  the 
final  OFP  Elock  Change  assembly  are  stored  on  magnetic  tape  and  hard  copy  listings 
are  maintained  on  microfilm  or  microfiche.  The  OFP  Block  Change  Requirements 
Document  defines  the  initial  block  change  definition  while  the  final  release  con¬ 
figuration  is  documented  using  the  previously  described  Documentation  Program. 

These  documents  become  a  part  of  the  OFP  Block  Change  Version  Description  Document 
(VDD).  The  Computer  Program  Change  Proposal  becomes  the  system  manager's  official 
configuration  control  document  and  is  updated  as  required  to  reflect  the  final 
released  OFP  configuration.  All  formal  test  requirements,  plans,  procedures,  and 
reports  become  a  part  of  the  VDD  and  are  a  record  of  actual  OFP  performance.  The 
OFP  Block  Change  Report  is  a  summary  of  total  block  change  activity  and  results. 

The  System  Program  Description  Document  (SPDD)  is  the  actual  OFP  specification 
and  is  updated  with  each  block  change.  It  describes  each  of  the  OFP  subroutines 
in  detail  and  includes:  narrative  descriptions,  inputs/outputs,  interfaces, 
logic,  timing,  equations,  and  flow  charts.  The  VDD  is  the  historical  record  of 
the  OFP  Block  Change  and  includes  all  other  block  change  documents.  In  summary, 
the  OFP  source  data,  SPDD  and  program  listings  actually  define  the  newly  released 
OFP  and  the  VDD  defines  the  OFP  Block  Change  to  it.  Technical  orders  generally 
aren't  considered  configuration  control  documents  but  are  shown  because  of  their 
importance  to  the  user  and  because  of  the  detail  they  offer  in  describing  the 
OFP's  and  their  relationship  to  the  aircraft  system  operation.  With  the  excep¬ 
tion  of  the  technical  orders,  all  documentation  is  stored  and  maintained  by 
engineering. 
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PROB/REQMTS 

INVESTIGATION 


•  OPERATIONAL  SOFTWARE  ] 

REQMTS  OOC  (OSRO)  U 

•  OFP  SOURCE  MAG  TAPfJ 

•  OFP  BLOCK  CHANGE  ~~1 
REQUIREMENTS  DOCUMENT  J 
•COMPUTER  PROGRAM  CHANGE  1_ 
PROPOSAL  (CPCP) 

•  PROJECT  TEST  PLAN  - 

•FLIGHT  TEST  REQUIREMENTS - 

•  FORMAL  TEST  PROCEDURES 

•  MASTER  ENGR  PROG.  TAPE 

•  MASTER  ENGR  PROG.  LISTING 

•  MASTER  OFP  SOURCE 


•CONFIGURATION  FREEZE 


•  AISF  CONFIGURATION 

•  FLIGHT  TEST  AIRCRAFT  CONFIGURATION 

•  MISSION  &  -WEAPON  CONTROL  PROG  CONFj 

•  MASTER  ENGR  ADDENDUM  I 

•  MASTER  ENGR  ADDENDUM  DOCUMEN  TAT  ION  J 

•  MERGE  PROGRAM  TAPE  - 

•  PRODUCTION  PROGRAM  SOURCE  T _ 

•  PRODUCTION  PROGRAM  TAPE  _J 

•  FINAL  TEST  REPORT 

•VERSION  DESCRIPTION  DOCJMENT 

•  SYSTEM  PROGRAM  DESCRIPTION  DOCUMENT 

•  MASTER  SOFTWARE  REQMTS  OOCUMENT 

•  TECHNICAL  ORDERS  AND  TCTO*  _ 

FREEZE  *OFP  BLOCK  CHANGE  REPORT  - 


Figure  B-7.  OFF  Con  f  i^ur.if  ion  Control  Document.-; 
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STRUCTURED  DESIGN?  -  DESCRIBE 
Minimal 


STRUCTURED  PROGRAMMING?  -  DESCRIBE 
Minimal 


CODING  GUIDELINES:  Experience  -  A  small  group  of  mechanization  engineers  is  used 
on  each  aircraft. 


CHANGE  ENTRY  METHODS:  CRT  terminal.  Interdata  is  used  for  an  on-line  record. 


SCHEDULE:  Formal  published  milestones,  formal  block  change  schedule. 


REPORTING:  Informal  in-house  reporting.  Formal  reports  to  users  are  via 

scheduled  meetings  (Ref.  Figure  3,  p.  B-10). 


COMMENTS: 


DOCUMENTATION: 


REQUIREMENTS:  Current  requirements  are  defined  in  meeting  minutes  and  in 
change  summaries  developed  by  engineers.  See  Computer 
Program  Change  Request  on  p.  B-20. 


DESIGN:  The  "dot"  files  are  used  for  design  documentation.  They  are 

described  on  pp.  B-21  and  B-22. 


USER:  User  documentation  is  provided  through  formal  changes  to  the 

system  tech  orders. 


See  Documentation  Guide,  pp.  B-23  through  B-42. 


PROGRAM  PROBLEM  REPORTING  SYSTEM: 

Users  generate  Computer  Program  Change  Requests.  These  are  formally  logged 
by  MMECP,  then  analyzed/prioritized  at  the  Requirements  Review  Meeting 
with  users. 


COMMENTS: 
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COMPUTER  PROGRAM  CHANGE  REQUEST 


DATE:  28  Sept  1979 


Entered  by  SM/ALC 


I  .D .  Number 


1.  TITLE:  Enter  descriptive  title 


2.  DATE:  Enter  prepared  date 


3.  COMPUTER  PROGRAM  IDENTIFICATION: 


Enter  identification  of  program  affected 


DESCRIPT ION /PRESENT  OPERAT ION : 

Describe  in  detail  the  characteristics  of  computer  operation  or  use  as 
presently  mechanized,  including  aircrew  actions,  observed  reactions  of 
various  cockpit  displays  correlated  with  inputs  to  the  system  (including 
aircraft  maneuvering  or  switch  changes),  any  test  data  available,  and  any 
other  information  which  might  assist  in  identifying  the  cause  or  which 
might  aid  in  implementing  the  correction  or  change. 


5.  DESIRED  OPERATION: 

Describe  the  characteristics  of  computer  operation  or  use  desired  as  a 
result  of  this  change,  using  the  same  guidelines  as  under  "Present 
Operation. " 


6.  REASON  FOR  CHANGE: 

Present  the  rationale  behind  the  need  for  this  change,  emphasizing  the 
relative  importance  of  the  current  problem  and  the  desired  result. 


7.  CHANGE  HISTORY/RELATED  CHANGES: 


Information  to  be  supplied  by  Sacramento  A LC 


8.  REQUESTED  BY: 

Person  to  be  contacted  for 
further  information. 


9.  REQUESTING  AGENCY:  COORDINATION 
Wing  coordination 


Name  Orgn  Phone  Name 

10.  REQUESTING  COMMAND:  APPROVAL  11.  SUPPORTING  AGENCY:  APPROVAL 
SAC /TAC/V SAFE  SM/ALC 


re 
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File  Designation 

File  Content  and  Structure 

axxx 

File  series  name:  a  indicates  aircraft  series; 
xxx  is  change  number. 

axxx . P 

CHANGE  STATEMENT  —  File  is  for  insertion  of  a  change 
statement . 

TITLE : 

CHANGE  REQUIREMENT: 

CURRENT  MECHANIZATION: 

OBJECTIVE : 

NOTES : 

STATUS : 

axxx . M 

MECHANIZATION  —  A  narrative  which  is  source  data  for 
update.  Note  if  change  as  mechanized  is  different  from 
requirement . 

DATE  OF  LAST  UPDATE: 

DESCRIPTION : 

axxx . K 

KEYINS  —  For  generating  addendum  tapes.  Machine  language 
code  for  patches  entered  prior  to  executing  a  compiled 

OFP.  Assembly  language  statements  are  not  required  but 
provide  design  interpretation  of  ML  code.  Note  required 
General  Navigation  Computer  and  Weapons  Delivery  Computer 
cues . 

$GNC  -  KEYINS 

LOC  IS  WAS  CORRESPONDING  AL  CODE 

(address)  (revised  (old 

ML  code)  ML  code) 

$END 

$WDC  -  KEYINS 

LOC  IS  WAS  AL  CODE 

$END 

axxx . R 

REASSEMBLY  —  Similar  to  KEYIN,  but  used  to  reassemble  a 
program. 

$GNC  -  REASSEMBLY 

(Exact  card  image,  punched  cards  format  previously  used 
fer  reassembly) 

$END 

l 
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File  Designation 


axxx. I 


File  Content  and  Structure 


axxx.F 


axxx.G 


TEST  PROCEDURES  —  Step-by-step  test  procedure  to  checkout 
a  change. 

FLIGHT  TEST  REQUIREMENTS  —  Contains  information  for  flight 
test  of  OFP  change.  Contains  summary  of  change  and 
requirements  for  test  execution  (digital  channels,  test 
parameters,  success  criteria,  et.al.). 

GLOSSARY  —  List  of  any  new  labels  or  mnemonics. 
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.  X.F .  -QPj.  A  N-AX10N_ 

CP 

_.CF  OVERVIEW  . 

CF 

_CJL  Variables^  . 
cf 

_C£ _ 

CF 

_JCI_ExTeRNal5 _ 

Cl 


Cl 

Cl  remarks 

Cl 

_CI  .  _ 


r  * 


j _ STATE  what  The  program  nnfB. _ 

J  OUTLINE  THE_LQGIC  STPUrTURE. _ _ 

_1 _ SEPARATELY  DEFINE  EACH  VaRTARLE  WHOSE,,  NAME  DOFS 

NOT  ADEQUATELY  DESCRIBE  ITS  FUNCTION,  type,  dr 
_ tlSJLGJL. _ 


DATA  FILES  ACCESSED  BY  the  program  and  their 
_LflCA-IlQN. _ 


A  insert  comments  to  describe  data  . structures  anp 

UNUSUAL  PROGRAMMING  TEchniOUfS  and  REQUIREMENTS. 

THfSE.  COMMENTS  SHOULD  CONTAIN  ANY  INFORMATION _ 

NECESSARY  TO  UNDERSTAND  THE  PROGRAM. 


CO  USER'S  GUIDE  t  A  USER'S  GUIDE  IN  THE  SOURCE  LISTIN5  is 

—CT _ OPTIONAL, _ 


NOT E j  DESCRIPTIVE  COMMENTS' SHOULD  BE  GENEROUSLY  USED  THROUGHOUT  THE 
_ _ S OJJ  fi C E _C Pj  E,  1 0_D E Sc RLg£_  WHAT  IS  HAPPENING. _ 


OTHER'  DOCUMENTATION  NEEDEDT 

source  LIS tTngTTi ^“so bo  ‘ UR  A sTf^bled 

_  USEf  ’  S  J>  UJ  OE _ _ _ 

LOCATION  OF  JCRSTREAMS/CSS  FILES  0*  MACROS 
_ _  _  aBEOCTATEC  WjJH  THE  PROGRAM _ 


CONFiDOCGUIDE.MAN 


documentation  standard  2 
subroutines 


CM 

_ CP  EXPLANATION 

CP 

_ Cf  -Parameters _ 

cp 

CF 


ci  externals 

CI _ 

CI 

ci 


CI  Remarks 


state 


THE  SUBROUTINE, 


LIST  all  EXTERNAL  SUBROUTINES,  FUNCTIONS  and 
-BAlA-PJ LES  ACCESSED  BY  THE  SUBROUTINE  OR  WHICH 
CALL  THIS  SUBROUTINE, 

I NSER’T  COMMENTS  TO  DESCRIBE  data  STRUCTURES  ANn 
UNUSUAL  PROGRAMMING  techniqufs  and  RFOUIRFMFnTS. 


THESE  COMMENTS  SHOULD  CONTAIN  ANY  INFORMATION 
NECESSA RY  TO  UNDERSTAND  THE  SUBROUTINE. _ 


NOtEi  descriptive  comments  should  be  gfnerousl*  usfd  throughout  the" 
source  code  to  describe  rhat  is  happening 


documentation  standard  s 

LIBRARY  ROUTINES 


-  _CM  IJTLE. 

t  TITLE  OF  LIBRARY  ROUTINF 

CM 

.  CM  JJ^TRY ...POINTS 

1 

CM 

_ CM  LIBRARY  Name 

_ 1 _ 

CM 

_ _cm  date  of  last  changf. 

CM 

CM  PRQGRAMMFS 

| 

CM 

CF  EXPLANATION 

l  STATF  WHAT  THF  LIRRaRY  ROUTINF  DOFS.,, 

CF 

CF  OVERVIEW 

_ «  OUTL1NF  THF  LOGIC  STRUT  TURF  . _  _ _ 

CF 

_ CF_P.iRamETeRS _ I _ DEFINE  VARIABLES  WHICH  are  PASSED  TO  AND  FROM 


CF  THE  ROUTINE. 

XE _ 


Cl 

JI 

externals 

1  LIST  ALL  EXTERNAL  SUBROUTINES,  FUNCTIONS  AND 

DATA  FILES  ACCESSED  BY  THE  LIBRARY  ROUTINF. 

Remarks 

1  INSERT  COMMENTS  TO  DESCRIBE  DATA  STRUCTURES  AND 

Cl 

Cl 

UNUSUAL  PROGRAMMING  TECHNIOUES  and  REQUIREMENTS. 

THESE  COMMFNTS  SHOULD  CONTAIN  ANY  INFORMATION 

Cl 

Cl 

necessary  to  understand  the  library  routine. 

CO 

USER'S  GUIDE 

1  A  USER'S  GUIDE  IN  The  SOURCE  listing  is  optional. 

NOTE!  DESCRIPTIVE  comments  SHOULD  BE  GFNFROUSLY  used  THROUGHOUT  The 
_ SOURCE  _COi>F  TQ  DESCRIBE  WHAT  IS  HAPPENING. _ 


OTHER  DOCUMENTATION  NEEDEOl 


SOURCE  LISTING 

U5EPJJ_CMJ.DE _ 


BOILER  PLATES  FoR  THE  STANDARDS  ARE  CONTAINED  IN  THE  FOLLOWING  ! OCATIONSl 

Interdata t  svstTdocstd.frm/s 

_harrisi _ systaqocstd _ _ _ _ _ _ _ 

RECORD  NUMBERi  PROGRAM  5-OSi  SUBROUTINE  50-8  0  r  LIBRARY  ROUTINE  65-125 
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EXAMPLE  I  program  documentation 


CM 

_ c 

CM 

c  f  -Cxpjji.Nm.oM_ 

cf 


cf  overview 


management,  the  program  will  request  a  pack  number 


NOT  ACCESSED  WITHIN  THF  PREVIOUS  7  DAYS, 


I  PROGRAM  PACKPURGE | 
INTlALJlATTONi 


while  packpurge  not  complete 


GETAREAINFOi 


THEN  BEGIN 


THEN  BEGIN 


then  ELImINAT£AREA» 
N 


CF 

i  variables 


ci 


XTERNALS 


parlst  is  the  parameter  list  and  buffer  a 


SOASAVE 

FLIST  IS  THE  PARAMETER  LIST  F OR  THE  SYSTEM 

eliminate  routine 

_  ALL  VARIABLES  ARE  GLOBAL _ 


_  _CI _ REMARKS _ j _ THE  PROGRAM  IS  COMPILED  AS  A  FORTRAN  PROGRAM  FOR 

CI  ~  EASE  OF  I/O, 

_ 51 _ due  to  the  INTERNAL  OPERATION  OF  VULCAN,  THI s _ 


CI 

I _ 


CI 

_C  I _ 

CI 


PROGRAM  MUST  BE  RUN  AS  *ACUTR  IN  ORDER  TO 
UTILIZE  THE  system  ROUTINF  SDASAVE.  IN 


TO  EFFECT  THIS  THE  PROGRAM  SHOULD  BE  EXECUTED 

J}Y A  JOB  STREAM  FILE  WHICH  RENAMES  ACUTIL  TO _ 

TEMP,  PACKPURGE  TO  ACUTIL,  EXECUTES  ACUTIL 

AND  UPON  COMPLETION  RENAMES  ACUTIL  TO _ 

PACKPURGE,  TEMP  TO  ACUTIL, 


NRITEH.POO) _ 

FORM At! ■  ENTER  PACK  $  TO  BE  PURGED") 

J»E A_0 ( 3,90!)  TRACK _ 

FORMAT(IJ) 

MR1TE(3.90Z)  IPACK _ 


ORMaT (?X, 13) 
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STOP 

jSf 

OLTfST  BLOK  1 
PAHLST  BLOK  2<i. 
PL  I  ST  BLOK  | 
_£LIST_BLQK_J _ 


ARCNT  BLOK  J 

THA _ 

TAM 

TLO 

BLJ 

_ J)  A  LA¬ 
PP? 

.  „  .  TEM 

BLU 

_  .  -  SOE 

TPM 

_ BLJ _ 

BO  Z 

.  I*lA 

BON 
BLJ 
BN? 

_ au_ 


MLOOP 


-JP-ACK _ 

PARLST+O 

J?ARLSI _ 

SOASAVP 

_J _ 


FIRST  CALL  TO  DASaVE 
FUNCTION  COPE  TU  fig I  ALL  AREAS 


DONE 

ap.chl_ 

STIMf 

_7 _ 

POATp 

C  Ta  PEA  - 


NO  AREAS  EXIT 
_Nil.Ma£P_DF.. 

6ET  TODAYS  DATE 
_ SllpTRifT  7  nAYS 


INITIALIZE  PURGE  DATE 
SET  K  Rffi-ISTfR.  TO  iRFa  HI  OCK 


DONE 

_6jK.  _ 

MLOPP 

OLTfSL 

MLOOP 

_ACCES?_ 


NO  MORE  AREAS  TO  PROCESS 
-CHECK  IE  DATA  FILE  OR  PROGRAM  PH  P 


PRQGRAM^FILE^GET  NEXT  AREA  BLOCK 


YES,  GET  NEXT  AREA  BLOCK 
CHECK  last  ACCESS 


BON 

BLJ 

MLOOP 

£UM _ 

WITHIN  T  OAYS  get  next  AREA  BLOCK 
TO  long  eliminate  it 

HVIC 

MLOOP 

get  next  area  block 

GETAREA  ROUTINE 
«sss»»sss»sa»ss 


ON  pNTRV  TO  This  routine  LOC  ARCNT  CONTAINS  CURRENT  BUFFER 
POINTER. 

SUBTRACT  ?n  f AREA8L  OCK  SIZF). 


7 E  NOT  POSITIVE  DAC ALL  ELSf  hove  POINTER  To  K  REGISTER  a  RETURN. 

.  DAC-ALLl _ 

CALLS  sdasave. 

TRANSFERS  BUFFER  COUNT  TO  ARE ACQUNT .  _  _  _ 

Rp turns  to'  mainline  if  nothing  in  buffer  i.e  done. 

EL.SE  RE-ENTERS  GETAREA. _ _ 


GETAREA 


OACAiL 


AOK 
0  AC 


•2V 

arcnt 


_  HOVE  POINTER  to  next  area  data  IN  BUFFER 

ADDRESS  OF  LOCATION  TO  ADD  TO 


BNP 

OACALL-. 

BUFFER  COMPLETELY  PROCESSED  GET  NEXT  BUFFER 

TMK 

BUC 

ARCNT 

0,  J 

MOVE  POINTER  TO  K  REGISTER 

rftupn  to  mainlinf 

TLO 

BLJ 

PAPLST 

SOASAVE 

GET  ADDRESS  OF  PARAMETER  LIST 

CALL  SYSTEM  routine 

data 

RN7 

0 

sao 

not  THF  FIRST  CALL  SO  0  HERE 

PROBLEMS  SENp  ERROR  MESSAGE 

T£M 

BO? 

ARCNT 

BUCOJ 

move  buffer  size  TO  ARCNT 

ALL  DONE  RETURN  WITH  ZERO  FLAG  SFT 

BUC 

GT  AREA 

CO  SET  POINTER 
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7 


TMD  §#K 
TpP._.jELI  $!*?_. 
BN?  SOI 


GFT  AREANAME  FROM  BUFFER 


GET  QUALIFIER  FROM  BUFFER 

PUT  IN  PR A M  LIST _ 

PROBLEM  SEND  ERROR  MESSAGE 


t 

t 

ACCESS  ROUTINE 

i 

*  < 

6 

ETS  LAST  ACCESS  DATE  AND  PURGE 

DATE. 

SUBTRACTS  PURGE  DATE  FROM  ACCESS  DATE. 
.RETURNS.  _ _ _ 


«  _ 

ACCESS 


THE  17, K 
TMA  OT1ME 


GET  LAST  ACCESS  DATE 
GET  PURGE  OAT 


c  _ _ _ 

40  WRITE (J. 400) 

400  FORMAT ("  ERROR  in  SdaSaVE  ROUTINE  CONTACT  PROGRAMMER") 
C"  GOTO  50 


C  _  THE  FOLLOWING  DISPLAYS  ERROR  MESSAGE  FOR  SELIM  ERROR _ 

C 

41  _WPITE(5.41v) _ _ _ _ _ 

410  FORMAT (*  ERROR  IN  SeLIMINaTE  ROUTINE  CONTACT  PROGRAMMER^ 

C _ _ _ 

c 

c  _  COMMON  EXIT  LOGIC _ 

c  So  “Rewind  »o 

r  ^l  PEAP(1Q,S00)VARIABLE  list _ 

'IF (EOF) GO  TO  60 

C  WP I  TE(6f  50?)  VARIABLE  LIST _ _ _ 

C  60  TO  51 

C  60  CLOSE  3  6 _ 

“'end 
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EXAMPLE  I  SUBROUTINE  DOCUMENTATION 


CM 

SUBROUTINE 

GTOATE (T£MP) 

CM 

CM 

title 

1 

GTOATE 

CM 

CM 

DATE  of  last 

CHANGE  | 

B  NOV  7s 

CM 

programmer 

t 

m, tavlor  t  j.claar 

CM 

CM 

CF 

EXPLANATION  — 

1 _ lij  iSL_&U &RP ULLNE  CONVERTS  A>i  ALRLMABEJIC  MjQNIH _ 

cf 

cr 

CF 

_C1L 


n AmE  to  a  NUMERIC  VALUE.  THIRTEEN  days  are 
ADDED  TO  THE  DATE  Ifl.  ALLOW  FflR_CHECK_lN6  FOR. 


DELINQUENT  TASK  REQUESTS.  CROSS-OVfR  TO  the 
NEXT  MONTH  AND/OR  YEAR  IS  TAKEN  INTO  ACCOUNT. 


RaRamETeRJL 


CF 
Cl 
Cl 
Ci 
Cl 
JLL 
CI 

-v  remarks  ...  _ i-Pates  »1LL  ndt be  converted,, -BEIRnd 


externals 


_ I  TEMP  -  ALPHANUMERIC  INPUT/OUTPUT  OF  DATE, 

format  i 
~  ~t  Failed  by  main 

_ located  in  trtshain _ 


CI  _ _ _ _ _ 

C  data  definition 

_ INTEGER  _TEHP(3),YOAU-ggf23 _ 

COMMON  /idate/ydate 

C  ...  END  DATA  DEFINTTON  _ 

c  get  NUMERIC  date  for  TEST  IN  CALLING  ROUTINE 

00  10  1*1.12  _ 

IF(TEMP(2).EQ,V0ATE(I,n)  GO  TO  20 

_  10 _ C  ON  TINUE  _ _ _ 

WRITE (3. 1  Ot>0)  TEMP(2) 

1000  EORM*T( 'OMONT.H  GIVEN  (’Afl.1)  IS  WRONG  ENDING  SESSION* ) 

CALL  EXIT 

c  set  alpha,  month  to  numeric  month _ 

20  T£MP(2)«i 

_ c  ADO  IN  13  FOR  TWO  KEEK  CHECK _ 

TEMP(1)«TEMP(1)M3 

C  CHECK  TO  SEE  IF  IT  IS  INTO  ANOTHER  MONTH _ 

IFCTEMPM j.LE.VOATECI.2))  GO  TO  9909 

c  _TE3  SUBTRACT  OUT  FOR  DAYS  INTO  NEW  MONTH _ 

TEMP  Ct  )*TEMP(n-TDATC(l.2) 

C  INCREMENT  month  counter _ 

TEMP(2)*TEMP(2)t| 

C  CHECK  TO  SEE  IF  INTO  NEK  TEAR _ 

IF(TEMP(2).LE,I2)  GO  TO  999* 

ADO  TO  YEAR  COUNTER  (KILL  NOT  WORK  FROM  1999  TO  2000) _ 

‘  fEMP(3)*ffMP(3)*l 

C _ ENQ.  OF  DATE  ROUTINE _ 

9999  'RETURN 

ENO _ _ 


EXAMPLE!  LIBRARY  SUBROUTINE  DOCUMENTATION 


fM 

TITLE 

1  1UIRTN 

CM 

CM 

ENTRY  POINTS 

_  J _ JUUi  IN _ 

CM 

CM 

CM 

CM 

LIBRARY  NAME_  |  OFPlIB _ 

date  op  last  change. _ w  may  7? _  __  ___  _  _ 

CM 

CM 

programmer 

1  KARL  W  RASS 

CM 

CP 

explanation 

1  the  buffer  starting  at  I BUFF  and  FOR  NCHAR  RYTfS  long 

CP 

CP 

IS  SCANNEO  LOOKING  FOR  a  VaLID  DATE  ANO  TIME  IN  *ScIt. 

THE  OATf  IS  CONVERTED  TO  A  BTNARY  W'ORD  AND  THE  TlMF  IS 

CP 

CP 

CONVERTED  TO  another  BINARY  WORD,  THE  APPROPRIATE 

STATUS  IS  RETURNED.  THE  DATF  can  9F  FTTHFR  IN  INTFRDAT 

CP 

CP 

( E ,  G .  pa/01/77)  OR  conventional  (2a  .)an  77)  OR  JULIAN 
(77,02ai ,  TIME  IS  IN  HHlMM,SS  AND  IF  NONE  IS  GIVEN 

CP 

CP 

.  '  THEN  12|00|00  IS  ASSUMED. 

CP 

CP 

vf 

overview 

1  SCAN  THE  BUFFER 

if  the  form  is  Julian 

CONVERT  THE  DATE  TO  BINARY 

CONVERT  THE  TIME  TO  RlNARY 

CP 

CF 

return 

ip  the  form  is  dd/mm/yy  or  do/mmm/yy 

CP 

CP 

IF  the  YEAR  IS  LEAP  year 

IP  THE  MONTH  is  later  Than  FEB. 

CP 

CP 

ADD  1  day  to  total  days  in  date 

CONVERT  DATE  TO  BINARY 

CP 

qp 

CONVFRT  TIME  TO  BINARY 

RETURN 

CP 

Cl 

parameters 

1  INPUT! 

Cl 

Cl 

IBUFF  •  BUFFER  START  ADDRESS  WHERE  THE  DATE/ 

TIME  IS  LOCATED 

Cl 

_il 

NCHAR  •  LENGTH  IN  BYTES  OF  IBUFFj  l«  FORhaT 

Cl 

Cl 

OUTPUT  | 

IflIN  -  IBIN(1)  IS  BINARY  DATE 

Cl 

Cl 

18 IN ( 2)  IS  BINARY’ TIME 

ISTAT  •  STATUS!  RANGE  -fc  •  01  I«  FORMAT 

Cl 

Cl 

externals 

1  CALLS  FSCANf  LOCATED  IN  SYSlUSER  LIBRARY 

Cl 

Cl 

remarks 

1  after  calling  julbin,  subroutine  julian  must  be 

c! 

Cl 

CALLEO  TO  CONVERT  THE  BINARY  DATA  to  JULIAN 

FORMAT,  LEAP  YEAR  CALCULATIONS  WILL  BE  INCORRECT 

T 

•PROC  julbin 

BEGINNING  with  LEAP  YEAR  1980. 

98 

98  CONFiOOCeUIOE.WAN 


10 


ruo  or>i  k*«o  nho,  hon 


P 


% 

♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ ♦  ♦♦♦•♦ ♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ ♦♦♦♦♦♦♦ 

99 
t  nn 

c 

SUBROUTINE  JULBIN(IBUFF,IBIN,NCHAR,ISTAT) 

101 

102 

c******************** ***************** ♦♦♦♦♦♦♦♦♦ ♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦♦ 

DIMENSION  IMQNTHf  121.1  TEXT  i  2  1 . 1  TABLE ( 121 . T8IN (21 . 10ELIMI31 _ 

103 

104 

C 

DATA  IHONTH/ • JAN  ','FEB  * , • HAR  • , • APR  •. 

105 

inti 

*  'NAY  ','JMN  ','JUL  »,'aug  », 

*  • SFP  '.'OCT  • . t  NO V  •  • • DEC  •/ 

107 

108 

C 

DATA  I  TABLE /0,  tl  ,  59, 9n , 1  Pn  ,  1  B 1  ,  1  8  t  ,  ?  1  2  ,  24  3 ,  27  3 ,  344  ,  X  34/ 

109 

1)0 

c 

DATA  IDEC/',  •/rIPfHnN/ii  1/ 

111 

1 1? 

c 

data  tdfltm'/'/  •  / 

113 

t  )4 

c 

r 

finding  out  in  what  form  the  buffer  is  in 

115 

1  1  A 

CALL  FSCAN(ISCINIT',NCH4R(IBUFF) 

CALL  F5CAN('pLIM'f J,IDFLIM.IRECA) 

117 

118 

CALL  FSCAN('GTOISPMDISP) 

CALL  FSCANt 'TEXT' . ITEYT. LENGTH) 

119 

120 

c 

c 

IF  The  form  IS  IN  JULIAN!  YR , DA Yl  GO  TO  70 

121 

122 

c 

IFILENGTH  .EG.  6)  GO  TP  70 

123 

124 

c 

FORM  MUST  NOW  BE  IN  DAY  MONTH  VR 

125 

126 

c 

c 

02  OEC  75 

02/12/75 

127 

126 

CALL  FSCAN( «ST0ISP«,I0ISP) 

CALL  FSC AN ( 'NUMBER’ .IDA V,NNUM,LFMGTH) 

129 

c 

IF ( 10 AY  , GE,  32  .OR.  I0AY  .LE.  0)  GO  TO  990 

131 

c 

c 

IF  THE  FORM  IS  in  DD/mn/VY  (02/12/75) 

133 

134 

CALL  FSCANC'GTOISP'.IDISP) 

CALL  FSCAN( 'NUMBER' . I M0N. NNUM, LENGTH) 

135 

136  _ 

IF(IMON  ,LT,  0)  GO  TO  2 

IFCIMON  .EQ.  0  .OR.  IMON  .gT.  12)  GO  TO  991 

137 

1 38 

ITEXTfl)  ■  IMONTH  (IMON) 

GO  TO  3 

139 

lao 

c 

c 

IF  THE  FORM  is  DO  MMM  YY  (u2  OEC  75) 

141 

U2 _ 

c 

2 

CALL  FSCAN('SToiSP'.tPISP) 

143 

144 

CALL  FSCAN('TEXT',ITE*T, LENGTH) 

IF (LENGTH  .NE.  3)  GO  TO  991 

145 

146 

3 

CALL  FSC AN ( 'NUMBER' » I YR, NNUM, LENGTH) 

IF(IYR  ,GT.  99  .OR.  I YR  ,LT.  0  )  GO  TO  992 

147 

146 
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i 


153 


REAP  a  4*J 

_  IFt.  IYR  BQ  TP  10 _ L&iL 

i  CONTINUE  155 

: - 156 

NON-LEAP  VEAR  CALCULATIONS  157 


DO  10  I  •  1 f 12 

_ IFCITExT(l)  .FQ.  IHONTH(I))  CO  TO  j>0 

10  CONTINUE 

_ GO  JJO..M! _ 

(0  NDAVS  a  ITABLE(I)  ♦  IOAV 

_ _ _ IYR _ a  ITS  *12**14J _ 

IBIN(l)  a  IYR  ♦  NDAYS 

. _ GO -TO  BO _ : _ 

L.  LEAP  YEAR  CALCULATIONS _ 


10 _ 

L$ _ 


I  ,±  Lil2 _ _ _ 

IF ( ITEXT ( 1 )  ,E0.  IMONThCD)  GO  TO  50 

-.CONTINUE _ 

GO  TO  901 

.ltd  .« G.T »._2 ) 1.0*1 _ 5 _ UL* Y._ ♦__! _ 

NDAYS  a  ITABLE(I)  ♦  IOAY 

_ I  YR__  a  IYR  «(2««161 _ 

IBIMDa  IYR  ♦  NDAYS 

GO  TO  SO _ 


z 

c 

c 

70 


c 


IF  THE  DATE  IS  IN  JULIAN  FQRMAT(YR.DAY) _ 

CALL_FSCAN<L'*Tf>I8PSI_0JSPi _ 

CALL  FSCAN('STCHARMDEC) 

CALL  F8C AN( < NUMBER 1 . I YR, NNUH, LENGTH) _ 

IF (IYR  ,GT.  .99  ,0R,  IYR  ,LT,  0)  GO  TO  092 

CALL  FSCAN(» NUMBER  SIP AY, NNUM, LENGTH) _ 

IFCTOAV  ,Gt.  *66  .OR,  IDAY  ,LT ,  0)  GO  TO  990 
IBIN(l)  a  IYR  »  (2«»16)  t  IDAY _ 


C 

SO 


PICKING  up  The  time  (HRiHIMtSEC) 


CALL  FSCAN( iSTCHAR* , ICOLQN) _ 

CALL  FSCAN( 'NUMBER', IHR,NNUM, LENGTH) 
IFCIMR.LT,  0  .OR.  IHR.GT.  20)  GO  TO  993 
CALL  FSCAN’CTnUMBER*  »M IN, NNUM, LENGTH) 


IFCMIN  ,LT.  0  .OR.  MIN  .GT.  60)  GO  TO  994 
CALL  FSCANC'NUMBE*', I  SEC, NNUM, LENGTH) 
IFCISEC  .LT.  0  .OR.  I8EC  ,GT,  60)  GO  TO  995 


159 
IhL 
161 
162 

163 

164 

165 

166 
167 
-16-8- 
169 
116 
171 
112. 
173 
lli 

175 

176 

177 

114 

179 

150  _ 

151 

182 _ 

163 


186 
167 

_ 186 

189 

_ 116 

191 
_ l?2 _ _ 

193 

_ 194 _ 

195 

196 

197 
196 


iein<2>  ■  36000  *  I  HR  ♦  600  *  MIN  6  10  MSEC  149 


_ I  STM  ■  0 _ IM 


c 

return 

201 

2n2 

c 

DEFAULT  OF  NOON  FOR  THE  TIME 

203 

c 

2na 

90 

IRINC2)  a  36000*12 

205 

ISTAT  a  0 

206 

RETURN 

207 

.  c ... 

2oa 

c 

errors  in  buffeb  passed 

209 

c 

210 

c 

invalid  day 

B  «1 

211 

c 

__  INVALID  MON1H 

B  -2 

212 

c 

invalid  year 

a  -3 

213 

c 

invalid  hr 

b  -a 

2ia 

c 

INVALID  MIN 

a  -3 

215 

c 

tnvai  rn  SFr 

*  -6 

216 

c 

217 

990 

ISTAT  b  -1 

218 

RETURN 

219 

8 

ISTAT  b  -2 

220 

RETURN 

221 

992 

ISTAT  b  -3 

222 

RETURN 

223 

993 

IF(IHR  .eq.  ■ 

21  GO  TO  90 

224 

ISTAT  8  -a 

225 

RETURN 

226 _ 

V9«  ISTAT  i  -5  227 


USER'S  GUIDE  PROCEDURES 


1,  PURPOSE 

G4v«  a  general  de*er1ot1on  of  the  program  atatlng  \  t  *  ourpoee  and 
_ funet  Ion, - - - 

2,  -  JMRJJLI _ _ _ 

Deaerlhe  the  input  Including  format,  content.  input  tnd - 

aequene  1  no, 

3,  OUTPUT  ~~ 

Deaerlbe  the  output  Including  forin»ti  content*  and  output  media* 

U,  OPERATING  PROCEnuRES 

U  at  the  step  by  ateo  procedure*  required  tot 

1,  Initiate  th#  program, 

2,  Maintain  operation, 

3,  Terminate  and  raatart  the  Program, 

Giva  an  operational  example, 

57~lTESTRfCTI0N3 

Oeaerfbe  any  ifftTYatTonB  aue r  <a  aFte  of  Input,  computer  ornceaaor 
uaad«_  avstem.  apace  required*  etc. _ 

6 ,  APPLICABLE  ERROR  MESSAGES _ 

^1  at_an^_error  meaaagc  which  "ay  be  dlaelayed  due  to  Improper  Input 
f 11 gone ration  error*  ate* 
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4-PI  ASSEMBLER  USERS'  GUIDE 


.  1 »  PURPOSE _ 

_ Tha  mlflf  ohleetive  of  tha  4-PI  Assambler  f«wHt«  orolaet  jj  ta 

allow  complete  processing  of  4-PI  programs  at  SMALC(  At  tHa  tlm*, 

_ a  svntaxlnq  version  ai._.t.b.a_aaaawbl ar  ajtlsta  for  un«, _ T-hla- >«filan 

acceota  a"  ordinary  4-PI  Assemble*  Input  (III  and  create*  from  It  * 
.  *vnta*ed  and  crosSmrefor*nead_1 I  at  I ng  of  the  Input.  Por  complete 
documentation  on  the  use  of  th*  assembler,  refer  to  the  IBM  CP-2 
_ _ _  end  4-PI  manual*. _ 

2,..  INPUT _ _ _ _ _ __ _ 

_  --TJM*  assamhiar  accepts  the  Same  Input  t h-  Qodoa  tmnhlff  with 
the  following  exceptional 


!•  Thg  JCL  cards  ape  not  needed  and  *r*  Ignored  If  found  In  th* 

..  _  .Input  f U *_, _ 

2t  Th*  update.  Pcoce* a flf— INCLUDE  card  must  eoatal-n  an Intardata _ 

filename.  Defaults  an*  set  to  th*  user  volume  and  no  extension, 

_ Th*  I "C luded  Hie*  muat  be  r>r*«en»  on  th*  Interdata  av^tem  and 

all  member  nam*  cards  must  be  deleted  from  the  data  sets. 


OUTPUT 


The  Outout  consists  of  th*  assembly  listing  Including  error  messages, 

_ warning  message*.  error  aummary,  Input  file  description#  cross  r,» 

ferenea  dictionary,  a«ter"al  symbol  dictionary,  special  remarks 
cards,  and_table_oi  ccn  laMj. _ 

OPERATING  RR5CI0uR.es _ 

... _ 4.1  initial  Preparation  Procedures _ 

Before  using  the  assembler  for  the  first  time.  It  Is  necessary _ 

to  prepare  the  Input  files.  It  Is  assumed  that  the  main  Input 

modu la. I s  already  located  on  an  Interdata  disc  each.  However, _ 

since  most  of  th*  £  *  BL  K  S  reside  as  data  sets  In  libraries  at  Ogden, 

_ th*  user  must  retrieve  these  data  sets  for  use  on  the  Interdata. 

A  separate  file  Is  needed  for  each  EXBLK,  and  the  member  nam* 

cards. must  be  deleted. _ These  files  n*y  be  given  any  Interdete _ 

filename.  If  m|n|m*l  text  editing  of  files  Is  desired# 

th*  above  files  should  b*  named  using  th*  user  volumy. _ 

th*  nam*  from  th*  INCLUDE  card#  and  no  extension.  If  these 

_ defaults  era  not  used#  the  user  must  modify  any  INCLUDE  card  In 

th*  seuree  f 1 1  a  to  Indleat*  th*  n*w  filename. 
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fl.2  OPERATION 


Th*  S»PI  Assembler  la  a  non* 1 nt * r*e t 1 ve  task,  It  la  called  by 

_ _ th#  jfellQ*ida_jtflte®«dtJ _ _ _ 

- A3*P.l  filename! _ .  f11aname2 _ _ _ 

* 

- - * _ 

wh#r* 

- jUlanamal-j-A  -the-  u.*e  r  1  a  1  aaui  i-i  1  a _ _ _ 

f11*n*me2  Is  th#  user'*  output  file 


Option*  for  the  output  file  arei 


1*  filename  -  output  goea  To  the  specified  file 

_2.  -  * _ »  Output  la  displayed  on  tha  CRT  screen _ 

3,  •  •  output  goa*  To  a  null  device 

.A. — blank _ -  output  ao»e  to  the_uaer»a  default  HaMlIf  

E"d  flfJa * k . Jla tu a  la  displayed  on  tha  CRT  aereen  a»  fa Hows j 

_f  nd_0F__T a SK_o _ Aj $ emhled  jti  th.  no.efrors _ 

END  of  Task  2  Assembled  with  warning*  only 
J[ND.J?F.  JASK-  1 _ Assembled.  w<  th-er.han . . . 

E  ramp  1  a  I  The  following  la  a  Short  example  of  a  «»PI  program 
and  an  INCLUDE  module  with  comments! 

"  SOURCE 

✓/RlH IfeGNSJOe  (»a35«.i,10>MMEC)»  'QFP1#  CLASStE 
//STHSCR.STSIN  DD  * 

_//cpaSms.incapd _pn  *  _ 

ASSEM  A.NSSG 

The  above  cards,  *11  JCL  and  the  ASSEM  card  are  treated  aa 
c onne nta  and  are  Ignored. _ 

ENTRY  DVY _ _ _  _ 

EXTRN  VSHIFT 

GAMBOL  EX8L_K_ _ 

INCLUDE  GAHPOL 


Module  GAMPOL  must  h*ve  been  brought  beek  from  Code",  separated 
Into  It*  own  file*  and  Placed  on  the  user's  default  disc.  The  _ 
filename  must  have  blanks  In  the  extension. 


f  ; _ fCQP 


IDS  1 6 
a 


BS3H  l 


EYBLK _ _ _ _ 

INCLUDE  FB0UIOBI6.SPC/G 


Module  10516  ha*  been  fully  described  a*  residing  on  dlac  FB01 
_ with  e«tenalnn  tBRC/C. _ 


USING  NL0CAL2,! 


END 


Include  Module!  *11  member  «a»e  card*  *uat  be  deleted  when 
_  -Cheat  lng__  the  1  nr  1  urta  f  1  1  a  t _ 

_ MEMBER  NAME  BAMB01 _ 

GAMBOL  EXBLK  DATE  64,142  B  SYSTEM 

_ LA.STXB2  „ _ ..ASSH _ 1 _ _ _ 

ml nutes. 


5l. _ RESTRICTIONS _ 

_ 1  j_ _  Tha _*  a * J  mum  nu mfc er  pf  label  t_a  llowed  1»  2000. _ 

_ 2*  JT  he  maul  mum  number  of  MACRO'S  allowed  la  50, _ 

3.  The  maHmum  number  of  1  nr.  1  uded  files  Is  9. _ 

6j _ ERROR  MESSAGES  _ _ _ 

_ Iw.O_ J_yPes.  Of  er ro.r s  are  Indie ated  bv  the  es»emb1erT _ The  first  dls- 

plavs  bad  file  1/0  to  the  CRT  Screen*  glvlnq  the  file  Involved  and 

_ the  1 /Q  status*  This  tvoe  Includes  errors  such  as  assignment  errprg 

for  the  lnput  Of  outPut  fl'e,  The  second  type  of  error  la  for  svnta* 

errors  and  warn! nos# _ These  era  merged  Into  the  output  listing  and 

appear*  beginning  in  eo1unn  2*  as  follows! 

*  WARNING  Q  COLUMN  0  NOT  BLANK 

_ «a  ERROR  ---  3  MULTIPLY  DEE  I NEO  LABEL _ 

__  Warnings  and  Errors!  _ _ _ _ 

_ Warnln^sj _ _ _ 

_ t,  SHORT  INSTR  DOESN'T  FOLLOW  A  SKIP*  COMPARE  OR  MODIFY  STORAGE 

2,  LONG  INSTRUCTION  GENERATED  IN  E*BLK 

3,  SHORT  INSTRUCTION  GENERATED _ 

4,  COLUMN'  4  NOT  BLANK 

_1 _ 5.  SHIFT  VALUE  TO  LARGE  —  HAS  BEEN  SET  TO  MAXIMUM _ 

6,  ENTRY  OR  EXTRN  DEFINED  BUT  NOT  USED 


105 


CONFlDOCGUIDE.MAN 


17 


E' ret  rj 


;.  .('.LEGAL  OPCODE 

i  L  L£5  AkJ.  AML -IN  LOCATION  FIELC 

3.  multiply  oeeined  LABEL 

M 


5,  ILLEGAL  CHARACTER  IN  COLUMN  15 

_ 6-..  illegal  labfi  tn  v  a  p  r  a  ft  i  p  ftfic 

7,  UNDEFINED  LABEL  USED 


UNDEFINED  set  or  ecu  label 

AL  NUMERIC  SPECIFICATION 


11,  INVALID  SHIFT  VALUE 

_i?.  INVALID  INDEX  REGISTER _ 

13,  I NV AL 10  HEX  MASK 

10.  ILLEGAL  VARIABLE  FTFLD  FORMAT _ 

15,  ILLEGAL  macro  Name  SPECIFIED 
NPSTINC  FXCFFnS  10  i  FVFI 


17.  MOPE  than  10  PARAMETERS  USED 

1 6 .  INVALID  MACRO  ARGUMENT _ 

19.  macro  table  limit  exceeded 

_  20j  MaCR0,  jnblk,  _e xbl j<- hJ-1  s T__a PP EA-RJBE £0.R£- e.x e c ii TabLE_c 0£ 

21.  INVALID  IFF  OR  IFT  INSTRUCTION 

22.  INVALID  GO  TO  OPERAND _ 

23.  INBLK  OR  EXBLK  DEFINITION  EXCEEDED  Maximum  SIZE 

20,  DEC  OR  BCI  OA.TA  TRUNCATED _ 

75.  ILLEGAL  COMBINATION  OF  INBLK,  EXBLK 
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TC0PV2  Feaalbl  1  Ity  Study 


Problem. 


under  M..T R  0  i  gill  not  amm  the  >nH»f  LLLaJ  or  tiau  rreated 
under  MTR02. 


Current  Implementation 


w^en  accenting  taoea  ejected  under  *TR02,  TC0Pv2  mutt  be  Implemented 

in  ..no  header  modej _ A  uter  mat  uter  the  adv  commend  tp  aaiHlOB  the 

tape  et  the  correct  ♦tie. 


Sol ut 1 on* 

1)  Modify  TC0Py2  to  Ignore  the  account  number  field  In  the  header 
- filet. — The  problem  eat  dltcuaten  with  the  afcLolneJ  a/nnremmer 

mho  eugoested  that  the  ehanoe  could  be  easily  Implemented  .  The 
general,  yaer  would  be  able  to  ui»  the  FIND  command  to  Innate  a 
file  on  the  taoe  and  then  proceed  with  •  R£*D  command.  The  time 
CQet  will  be  30  man  houre  and  20  machine  !<oupt, _ 

2)  Ute  the  current  Implementation.  Thla  reaulree  the  uaera  to  flrat 

ute  the  INDEX  command  todltolay  a  Hat  °f  all  filet  on  the  taoei 

the  count  the  numher  of  filet.  Including  both  header  and  data _ 

files.  and  use  the  ADV  Command  to  advance  the  proper  number  of 

filet  I  then  twitch _ to  NpHEADEff  mode  and  Proceed  with  a  REAP _ 

Command. 

3)  Recommendat 1  one 

It  la  recommended  that  TC0PY2  be  modi f led^  Thla  modification  *111 
make  taoe  file  acoultltlon  lett  comolleatad  for  the  general  uter. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


PERSONNEL  DESCRIPTION _ DATE:  28  19?9 

DESCRIPTION  OF  SKILL  LEVEL  AND  TYPE  (AF/CS/CONT)  OF  PERSONNEL  MAINTAINING  THIS  PACKAGE 

Below  is  the  official  position  description  for  a  GS-12  Electronic  Engineer 
(Computer  Systems).  This  description  outlines  the  basic  requirements  of  the  work 
to  be  done,  whether  performed  by  Civil  Service  or  contractor  personnel. 

I.  INTRODUCTION 

See  functional  statement  filed  in  Official  Position  Description  folder  and  the 
Sacramento  ALC  Organization  Directory  charts.  Incumbent  of  this  position  serves  as 
an  Avionics  System  Engineer  responsible  for  accomplishing  software  and  systems 
engineering  projects/tasks  for  avionics  embedded  computer  systems,  their  resident 
Operational  Flight  Programs  (OFPs)  and  their  support  systems  for  the  F-lll  and  other 
Sacramento  ALC  prime  aircraft  systems. 

II.  DUTIES  AND  RESPONSIBILITIES 

1.  Develops,  coordinates  and  carries  through  to  completion  blocks  of  work  of 
large  scope  containing  many  phases  of  which  two  or  more  phases  each  contain  several 
complex  features.  Plans  and  conducts  research,  development,  or  other  work  for  which 
precedent  data,  criteria,  methods  or  techniques  are  significantly  inadequate,  are 
controversial,  or  contain  critical  gaps.  Develops  or  originates  completely  new 
features,  in  addition  to  improving,  extending,  or  validating  currently  known  pre¬ 
cedents,  data,  methods  or  techniques.  In  accomplishing  the  above  incumbent  is 
responsible  for  the  development  of  modifications  and  changes  to  complex  aircraft 
digital  avionics  systems,  their  Operational  Flight  Programs  (OFPs),  and  laboratory 
support  systems  (e.g.,  the  Sacramento  ALC  F-lll  Avionics  Integration  Support  Facility 
(AISF)).  In  addition,  incumbent  is  responsible  for  the  investigation,  analysis, 
evaluation  and  reporting  on  avionics  system  performance,  problems  and  new  requirements 

2.  Develops  and  carries  through  to  completion  complex  changes  to  the  OFPs. 

Uses  the  F-lll  AISF  to  analyze  and  evaluate  OFP  requirements  in  order  to  develop 
optimum  implementation.  Investigates  potential  solutions  to  system  problems /change 
requirements  considering  tradeoff  analyses  Involving  implementation  costs,  algorithm 
developments,  timing  requirements,  memory  size,  hardware/software  integration 
requirements,  support  equipment,  personnel  capabilities  and  limitations,  data  package 
development  and  overall  magnitude  of  the  effort;  and  translates  these  change  require¬ 
ments  into  engineering  specifications  and  tasks.  Designs  the  change  mechanization 
and  integration;  develops  the  programming  code;  and  debugs,  tests  and  documents  the 
results.  At  all  times  assures  aircraft  system  integrity  and  compatibility;  and  meets 
resource  allocations,  performance  criteria,  cost  and  schedule. 

3.  Establishes  formal  test  requirements  for  OFPs;  develops  and  implements  test 
plans;  conducts  detailed  tests  using  the  full  capabilities  of  the  F-lll  AISF  and 
instrumented  flight  test  aircraft;  and  analyzes,  evaluates  and  reports  test  results. 

4.  Serves  as  project  engineer  for  the  design  and  development  of  changes  and 
modifications  to  the  AISF  hardware/software  resources  and  other  avionics  support 
systems.  Provides  system  engineering  support  and  assures  compatibility  with  the 
aircraft  avionics,  digital  computer  complexes  and  OFPs.  Establishes  change  require¬ 
ments  directly  with  the  AISF  and  avionics  support  systems  users.  Prepares  change 
specifications  and  plans  and  schedules  the  complete  development  and  implementation. 

3.  Conducts  studies  and  evaluations  of  systems  in  acquisition  and  determines 
support  requirements.  Performs  2612  studies,  prepares  Computer  Resources  Integrated 
Support  Plans  (CRISPs)  and  participates  as  a  member  of  Computer  Resources  Working 
Groups  (CRWGs). 
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6.  Prepares  contractual  engineering  proposals  and  associated  specifications 
and  work  orders. 

7.  Monitors  and  maintains  close  liaison  between  contractor  and  Air  Force 
activities  associated  with  the  engineering  support  of  digital  avionics,  embedded 
computer  systems  and  OFPs  for  Sacramento  ALC  prime  aircraft  systems. 

3.  Reviews,  evaluates  and  advises  on  the  effectiveness,  technical  adequacy 
and  suitability  of  work  and  proposals  of  others  related  to  digital  avionics  and 
OFP  support.  Evalutes  more  complex  vendor  proposed  modifications  for  requirements, 
feasibility,  completeness,  accuracy,  cost,  and  operational  and  logistics  impact. 

9.  Consults,  coordinates  and  attends  conferences  with  other  service 
activities  and  higher  headquarters  on  matters  pertaining  to  avionics  OFP  develop¬ 
ment  and  support.  Makes  recommendations  to  higher  authority  for  changes  to 
policies  and  practices,  based  on  knowledge,  experience,  engineering  studies, 
observations,  and  reports  received  from  service  activites,  and  defends  Sacramento 
ALC's  findings  and  recommendations.  Travels  to  contractor  or  other  government 
facilities  to  review  engineering  data  and  render  opinions  and  decisions  which  are 
normally  unreviewed;  maintains  liaison  with  other  government  activities  and  con¬ 
tractors  in  order  to  exchange  engineering  data  and  to  maintain  a  current  knowledge 
of  the  state-of-the-art. 

10.  Independently  determines  logical  approach  to  solutions  of  major  associated 
avionics  OFP  development  and  support  problems.  Carefully  weighs  the  advantages  of 
increased  systems  reliability,  maintainability,  etc.,  against  time,  cost,  com¬ 
patibility,  and  safety  of  flight.  Makes  and  evaluates  proposed  changes  to  the 
system  software  on  the  basis  of  established  hardware/software  interfaces. 

Establishes  supporting  projects  'with  other  engineering  personnel  and  directs  the 
integration  of  auxiliary  projects  toward  the  ultimate  objective.  Scope  of  project 
effort  is  broad  in  that  all  projects  consider,  as  applicable,  the  mission  of  the 
aircraft;  functions  of  associated  avionics  systems  (weapon  delivery,  navigation, 
reconnaissance,  radar,  instrumentation,  etc,);  communication/interface  requirements; 
flight  test;  computer  program  documentation  and  configuration  control;  and  vali¬ 
dation/verification  of  the  software.  Applied  research,  special  investigations, 
statistical  analysis,  etc.,  are  a  normal  part  of  the  incumbent's  effort  in  accom¬ 
plishing  his  duties  and  responsibilities. 

III.  CONTROLS  OVER  WORK 

Incumbent  is  under  the  supervision  of  the  Section  Chief  and  receives  technical 
direction  from  the  functional  group  engineers  and  other  senior  engineers  who  give 
assignments  in  terms  of  broad,  general  objectives  and  relative  priority  of  work. 
Extent  and  limits  of  assignments  are  mutually  discussed.  Incumbent  works  with 
considerable  freedom  from  technical  control  in  selecting  and  establishing  the 
proper  methods  for  attacking  and  resolving  complex  features  and  otherwise  carrying 
assignments  through  to  completion.  Controversial  policy  questions  are  resolved  by 
joint  consideration  with  the  supervisor  and  functional  group  engineer.  Completed 
work  is  reviewed  for  adequacy  in  terms  of  broad  objectives  of  the  work  and  for 
compliance  with  Air  Force  policies  and  regulations.  Decisions  and  recommendations 
based  upon  application  of  standard  engineering  practices  are  rarely  changed  by 
higher  authority,  except  for  reasons  of  policy,  public  relations,  or  budgetary 
consideration. 


110 


PREDICTIVE  SOFTWARE  C08T  MODEL 


CONTINUATION  SHEET _ DATE:  28  Sept  1979 

IV.  OTHER  SIGNIFICANT  FACTS 

1.  Fields  of  Engineering:  Electronic  -  55%,  Computer  Science  -  30% 

Aerospace  -  15% 

2.  In  addition  to  an  extensive  academic  and  professional  knowledge  of 
scientific  and  engineering  principles,  it  will  be  necessary  for  the  incumbent  to 
possess  a  special  faculty  to  do  successful  applied  research  and  establish  authori¬ 
tative  criteria  based  on  sound  engineering  principles  used  within  this  section  by 
joint  consideration  with  other  engineers.  At  most  times,  the  incumbent  will  be 
responsible  lor  several  projects  requiring  difficult  and  advanced  engineering  work 
of  a  high  degree  of  originality,  therefore  incumbent  must  have  a  thorough  and 
detailed  knowledge  of  avionics  digital  systems,  (e.g.,  inertial  navigation  systems, 
fire  control  radars,  stores  management  systems;  digital  controls  and  displays, 
etc.);  aircraft  embedded  computer  systems;  real-time  operational  flight  software; 
laboratory  support  systems  to  include  real-time  simulation  systems,  host  computer 
systems  and  avionics  system  hot  mock-ups;  software  configuration  management; 
software  documentation;  OFP  testing,  <-  iluation,  verification  and  validation;  and 
aircraft  performance  and  operation,  s.  jifically  in  the  areas  of  navigation  and 
weapon  delivery.  Must  be  experienced  and  knowledgeable  in  real-time  programming, 
mathematical  modeling,  computer  architecture  and  programming  languages. 

3.  Incumbert  must  possess  a  high  degree  of  professional  judgment,  skill, 
initiative,  planning  and  leadership  ability.  Also  must  possess  ability  to  maintain 
effective  personal  work  relationships  at  all  levels  and  to  justify  and  sell  his  own 
professional  viewpoints  in  conferences,  engineering  reviews  and  with  fairly  large 
groups  wherein  conflicting  points  of  view  are  represented.  Requires  an  intimate 
knowledge  of  functions,  organizational  structure,  jurisdictional  responsibilities, 
etc.,  of  USAF  and  elements  thereof. 

4.  The  incumbent  of  this  position  must  be  capable  and  willing  to  perform  TDY 
travel  in  accordance  with  the  Joint  Travel  Regulation. 

5.  Supports  and  takes  affirmative  actions  in  furtherance  of  Equal  Employment 
Opportunity  in  all  aspects  of  personnel  actions,  with  special  emphasis  on  Upward 
Mobility  and  other  special  programs. 

6.  Position  requires  a  security  clearance  of  Secret. 

7.  Performs  other  related  duties  as  required. 

8.  Subject  to  call  during  off-duty  hours. 

9.  All  personnel  will  share  in  the  responsibility  for  a  sound  industrial 
a  -ety  program.  Incumbent  is  required  to  comply  with  all  applicable  safety 
directives.  Unsafe  conditions  are  to  be  promptly  reported  to  the  immediate 
supervisor. 
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COMPUTER  FACILITIES  (Type,  Quantity,  Application,  Cost  &  Usage) 

The  basic  equipment  in  the  F/FB-111  Avionics  Integration  Support  Facility 
is  as  follows: 


Equipment 

Dynamic  Simulation  System  (Harris) 
System  and  Software  Engineering 

Flight  Test  Data  Reduction  (PDP) 

Off-line  Computer  Support  (Interdata) 

Integration  Test  Equipment  @  1.7x3 
Original  cost  -  $800K  each 

Subsystem  Testers  (11) 

Avionics  (loaned  out  of  spare  assets) 

F-lllF/Pavetack  Dynamic  Simulation 

To  be  added : 

F-111A/E  Hardware 


Cost 

($  million) 

12.0 

1.5 
2.0 

5.1  (replacement 
cost) 

3.5  (replacement 

cost) 

12.9 

2.6 
39.6 

1.6 

41.2 


Vendor  support  on  the  Harris,  Interdata  and  PDP  computers  costs  $308K/year 
I  plus  $126K /year  for  expendables  and  prototype  hardware  (split  50/50). 
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PREDICTIVE  SOFTWARE  COST  MOOEL 


CONTINUATION  SHEET  "  COMPUTER  FACILITIES 


DATE:  28  Sept  1979 


INTERDATA  8/32  System 
(Data  Reduction  and  MIS) 


2  Processors  1  megabyte  each 

8  40  mb  disc  drives  (4  switchable,  4  fixed) 

1  300  mb  disc  drives 
12  4  kb  Floppy  Drives 
1  Line  Printer 
4  Mag  Tape  Drives 
1  Paper  Tape  Reader 
1  Paper  Tape  Punch 
12  CRTs 

1  IBM  Selectric  Typewriter 
1  HP  Auxiliary  Printer 
1  Tektronix  Plotter 

3  ITE  (Integration  Test  Equipment)  Static  Simulator 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  -  COMPUTER  FACILITIES _ DATE:  28  Sent  1979 

Harr is/ 4  System 
(Dynamic  Simulator) 

2  test  stations 

2  ADAOE  (large  display  screen  on  test  station) 

6  processors  -  80K'  each 

2  SAS  (Simulation  and  Switching)  Interface  between  Harris  &  test  station 

6  CMACs  (Computer  Monitor  and  Control)  Interface  between  4pi  computer 

and  Harris 

1  card  reader 

1  card  punch 

2  paper  tape  readers 
8  mag  tape  drives 

1  CDC  line  printer 

2  Versatic  printer/plotters 
11  CRT 

2  teletypes 
6  10  mb  disc  drives 

1  40  mb  disc  drives 

2  300  mb  disc  drives 
1  paper  tape  punch 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  -  COMPUTER  FACILITIES 


PDP  11/40  System 
(Flight  Test  Data  Preprocessing) 

16K  words  memory 
1  Dec  Writer 
1  Card  Reader 
1  1.2  Mbyte  Disc 

1  9-track  tape  drive 
1  Paper  tape  punch/reader 
3  8-channel  brush  recorders 
1  CRT  display 
1  Versatec  printer/plotter 


PREDICTIVE  SOFTWARE  COST  MODEL 

CONTINUATION  SHEET  -  COMPUTER  FACILITIES _ DATE:  28 

TYPICAL  UTILIZATION  OF  HARRIS  COMPUTER  WEEK  OF  23-27  July  1979 

Time:  Mon  Tue  Wed  Thu  Fri  Sat 

0000  •  ...... 

0100  •  ...... 

0200  •  ...... 

0300  •  ...... 

0400  •  ...... 

0500  •  ...... 

0600  •  ...... 


0800 

1 

Harris 

Harris 

Harris 

(Maint) 

0900 

IV  &  V 

IV  &  V 

1000 

GD 

IV  &  V 

1100 

IV  &  V 

1200 

1300 

F 

IV  &  V 

F 

1400 

GD 

(Modif  & 

1500 

Upgrade) 

F 

1600 

1700 

MMECS 

GD 

F 

GD 

(Backup, 

1800 

Archive, 

etc.) 

1900 

A 

2000 

2100 

2200 

2300 


Sept  1979 


Sun 


K 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  -  SUPPORT  SOFTWARE 


DATE:  28  Sept  1979 


COMPUTER 


SOFTWARE  FUNCTION 


ESTIMATE  SOURCE  LINES 


INTERDATA  8/32 


SYSTEM 


166,957 


UTILITY 


SPECIAL  UTILITY 


42,841 


AGERD 


3,299 


6,764 

2,525 


PLOTTER 


OFP  UTILITY 


DATA  REDUCTION 


4,754 

13,286 

46,002 


287,124 


HARRIS 


SYSTEM 


292,953 


UTILITY 


34,494 


PLOTTER 


7,580 


4,000 


ADAGE 


6,714 


2,888 


SIMULATOR 


17,706 


13,674 


PDP  11/40 


UTILITY 


387,419 


22,619 

27,796 


Pages  B-53  through  B-71  provide  a  detailed  listing  of  the  support  software. 
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PREDICTIVE  SOFTWARE  COST  MOOEL 


CONTINUATION  SHEET 


DATE:  ?a 


soft-  ape  i  o  e  n  t  i  f  i  c  »  t  i  p  >. 


C'ORES'T  as  OF  i 


25JAN7R 


«f  y: 


1 

gd 

in 

t: 

dec 

N/C 
Tf  « 

\  t  “ 

M4  IT 

RFS 

GEn/RES 


s  HARRIS 
r  INTEPOATA 

=  general  i'r,YA*'ics 
I  IN  HOUSE 
s  TEXAS  1NSTPU“ENTS 
s  DIGITAL  EOUIPHENT  CORPORATION 
=  NO  SOURCE  AVAILABLE 
=  TEKTRONIX 

i  .ERSATEC 

s  M  a  I N  TE  na‘jCE  RESPONSIBILITY 
s  GENERAL  RESEARCH 


INTEPOATA  S/52 
UTILITY  SOFTWARE 


EST 

Ci  n a ME  S"R»  “AIT  SOURCE 

RLIFR  »ES  LINES  DESCRIPTION 


ACCOUNT 

• 

IN 

]H 

• 

2BB  » 

IhTERDATA  USAGE  REPORT  GENERATION 

?  AT 

IN 

«5. 

ALPHABETICALLY  lists  FILES  FRnM  DISC  RACK 

CApS 

T* 

IN 

63«, 

CONVERTS  CAPITAL  TO  shall  LETTERS  and  visa.VE»Sa 

CA«D JN 

T  u 

IH 

162, 

HANDLER  for  the  CARD  RFaDER 

COFYf’lF 

JH 

IN 

765. 

COPIES  FILES 

COPVT  APf 

tn 

IN 

206, 

DUPLICATES  PUNCHED  TAPES 

COCPRD 

i" 

TH 

507. 

PULLS  DOCUHENTATION  FRnH  SOURCE  FILES 

entry 

In 

IN 

IR3. 

COPIES  DATA  FROH  HEWLETT. PaC*adD  TERnINal 

CASSETTE  INTO  A  filf 

r-T-Ex 

i“ 

IH 

152. 

LISTS  ALL  OCCURRENCES  OF  A  CHARACTER  STk'TNr, 

IN  A  file 

L  r  H  I  N  v 

i“ 

IH 

R62. 

docuhent  inventory  rfport  generator 

IV*« 

IH 

TM 

513, 

LINK  BF Tween  The  InTeROATA  ano  HARRIS  cp-pMeR 

LIST 

i- 

IN 

2?0, 

LISTS  A  FILE  TO  THE  USER  TrRHlNAL 

m  a  N  M  0 ' 1  p  S 

Th 

IN 

2«IR. 

PERSDNnmel  UTJLI?AT]ON  REPORT  generator 

mIC«of&n 

!h 

IN 

?  1 1  R , 

REFORHaTS  FILES  TO  The  hIC“OFICHE  PRI'CESSINU 

FORMAT 

MTQpPY 

IN 

Tn 

??R. 

DUPLICATES  AND  VERIFIES  MAGNETIC  TAPES 

P  APT 

I* 

IN 

6?6, 

Co® I E S  A®?  FORHAT  data  TO  Punch  Tape 

P  n  I  *v  T 

TP 

TH 

M5. 

COPIFS  A  FILE  TO  A  HEWLETT-PACKARD  AUXILIARY 

• 

POI'-'TPR 

P'l^CHT, 

I  " 

I« 

1  o  s  a  , 

DIRECT  BIT  COPY  TO  PUNCH  Tape 

RE  ArF  TLE 

t" 

I* 

5u6, 

GfnfRaTES  a  FORhaTTED  list  FJlE 

prcPvf p 

T  i- 

?  N 

376. 

Recovers  file  from  backup  tape 

ap 

• 

T * 

IN 

• 

1S2. 

LIST  FILE'S  F*0M  "ISC  Pack  NT  iSpc 

PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  28  Sent  1979 


TSUI NV 

TH 

.  I” 

.  I0°6. 

SE^OVE 

IH 

.  IH 

.  212. 

RFSTo«E 

IH 

•  IH 

.  255 . 

REOUrSTS 

tH 

.  IH 

.  155. 

REWRITE 

IH 

.  IH 

.  2*1. 

Shift 

■ 

T 

* 

.  175. 

SORT 

lu 

.  IH 

.  250. 

TAPEDIR 

IH 

.  IH 

.  200 . 

T  C  OR  Y  2 

« 

IH 

•  IH 

.  aRoj. 

IE 

IH 

.  IH 

.  16257. 

terminal 

IH 

B  i  H 

.  26  1. 

tlist 

IH 

•  IH 

.  RPR. 

TYPF 

IH 

.  IH 

.  2°R. 

«R1Te 

t 

• 

IH 

.  IH 

.  226 , 

*  ******** 

* 

*  THE 

FOLLOWING  Cl's 

ASSIG 

IH 

.  IH 

.  "7. 

DfTf 

• 

I  W 

.  IH 

.  68. 

F !ND®A 

IH 

.  IH 

.  550. 

FSCAf; 

IH 

.  IH 

.  lfl56. 

LISTING 

IH 

.  IH 

.  s««. 

RtNOo" 

IH 

.  IH 

.  15. 

VIRme" 

» 

IH 

.  IH 

.  1158. 

follo- 

INC-  Cl' 

S  ABE  CON 

areanm 

IH 

.  IH 

.  1*1. 

.endfxd 

IH 

.  IH 

.  «1. 

f E^UVAR 

IH 

.  IH 

.  72. 

,ENTEYD 

IH 

.  IH 

.  253. 

,  E  N  T  V  A  R 

IH 

.  IH 

.  160, 

l  r  S  C  A  N 

• 

IH 

.  1“ 

.  <>5. 

FILEMG 

• 

IH 

.  3  u 

.  '  1 28 5. 

FIf:pTX 

• 

IH 

!  IH 

no! 

MVCHP 

• 

IH 

.  IH 

.  P5. 

total 

I 

• 

,  U28«l. 

MAGNETIC  tape  Inventory  report  Gf f.'EKATIOf. 
SEPARATES  CO“MENTS  PRO"  SOURCE  CODE 
REPLACES  COMMENTS  INTO  SOURCE  CODE 
Task  REOI'EST  and  SCHEDULED  REPORT  GENERATION 
RERRITFS  and  REPORHATS  DATA  IN  A  FTI.P 
SHIfTS  DATA  KITHIN  A  RECORD 
SORTS  A  FILE  IN  ASCE'DING  ORDER 
PRODUCES  A  DIRECTOPT  OF  A  BACKUP  TAPE 
COPIES  FILES 

PAGE-OPIENIED  TEXT  EDITOR 

SETS  HEWLETT-PACKARD  TERMINAL  CHARACTERISTICS 
LIST  A  FILE  TO  THE  USE®  TERMINAL 
COPIES  A  FILF  TO  AN  IB"  SELECTIC  TYPE  wR I Tf  P 
COPIES  A  FILE  TO  A  HEWLETT. PACKa»D  TERmIn»l 
CASSETTE 


GIVES  DAY  AND  time 

SEARCHES  A  FILE  FOR  CHARACTER  STRING 
“NS  A  BUFFER  FOR  SPECIFIED  DATA 


SCANS  FOR  DISC  FILE  name 

EXIT  ROUTINE  FOR  SUBPROGRAM  USING  .ENTFXO 
EXIT  ROUTINE  FOR  SUBPROGRAM  USING  ,ENTY»r 

entry  pomtine  fop  a  fixed  parameter  subprogram 

ENTRY  ROUTINE  FOR  AVAILABLE  PARAMETER  SUBPROGRAM 
SCANS  A  BUFFEP  FOR  SPECIFIED  DATA  (RE-ENTRANT) 
PROVIDES  INTERFACE  «ITm  SYSTEM  SERVICE  CALL 
T  (SVC  7 ) 

SCANS  A  BUFFER  FOR  A  SPECIFIED  CHARACTER  STRING 
TRANSFERS  characters  FRO"  ONE  PUFFER  TO  another 


IUTERDATA  B/J? 
SPECIAL  utility  software 


AGE»Dt 


tST 


Cl  namE 

S'ip. 
p !_  i  r  h 

M  A  I  T 
«fS 

SOURCE 

LINFS 

DESCRIPTION 

A$SE“«LY 

!  ih  ! 

IH  ! 

326R ! 

AGFRn  ASSEMBLE* 

total 

•  • 

•  • 

* 

• 

120 


PREDICTIVE  SOFTWARE  COST  MOOEL 


CONTINUATION  SHEET _  PATE:  Sept  1979 


u-PI 

EST 

SHP. 

*4]  T 

SOUPCE 

C! 

PLTFS 

LI'(FS  t>E  SC®  1°  TI  On 

45l°I 

a  • 

.  I H  . 

I H  ) 

Oils!  u-PI  ASSEMBLER 

BF0°" 

.  T  H  . 

IH 

1 b5 •  CONVERTS  A  FILE  FOR  TRANSMISSION  TO  U-PI 

.  IH  . 

IH 

101.  CONVERTS  A  FILE  AFTER  TRANSMISSION  FROM  u-PI 

ILl'-K 

.  1H  . 

1" 

293.  LINK  FROM  INTERDATA  TO  u-PI 

total 

•  • 

•  • 

a 

a 

4i76U. 

VC'S  (MICROPROCESSOR  DATA 

svste.msh 

EST 

S'lP- 

M  A  I  M  T 

SOURCE 

Cl  NA"E 

PLIFP 

RF  S' 

lines  description 

P  l  p  P  0 

•  • 

,  !H  4 

20*8*.  INTEL  SOSO  CROSS-ASSEMBLER 

"U“K 

.IP  . 

!H  . 

UJ6.  LINK  FROM  INTERDATA  TO  MDS 

T0T4L 

a  • 

a  • 

a 

a 

2525, 

FlCL  (FLIGHT  L I HE 

COMPUTER  LOAOfcPI 1 

EST 

SUP- 

m*  InT 

SOURCE 

Cl  ‘a-E 

PLIFK 

RES 

LINFS  DESCRIPTION 

a  » 

a 

FFOPw 

a  1*  . 

iv 

270.  converts  piles  f0r  transmission  to  flcl 

FLT'K 

.  I H  , 

IM  . 

U26.  LINK  RETnEFM  INTERPaTa  AND  PLCC 

total 

•  a 

a  • 

a 

a 

60*1 

PLOTTER 

(TEKTOOHI*) 

EST 

SUP- 

►'•ATT 

SOURCE 

Cl  *4“E 

P|  I  EH 

°ES 

LINES  DESCRIPTION 

PLOT  io 

•  a 

.  TE»  . 

IE“.  ! 

a 

a 

LI0 

IH  . 

5795.  ROUTINES  USED  TO  CONTROL  THE  PLOTTER 

plottfr 

a  T*  . 

IH 

059.  GENERAL  USER  PLOT  GENERATOR 

total 

a  * 

a  • 

• 

« 

u7Su* 

121 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTI N UATION  SHEET 


OATE:  28  Sent  197< 


If  TERDATA  p/32 

$YST£H  SOFTWARE 


Cl  Name 

SUR-  MAINT 

PLIER  res 

EST 

SOURCE 

LINES 

SaCKi/p 

• 

• 

INT  "iNT/IH, 

a75i ! 

OSEOIT 

InT  .INT/IH, 

2938. 

ROOTpNCW 

INT  . INT/IH% 

B«2, 

cal 

INT  .INT/IH, 

9667, 

CaLMaCRO 

INT  .INT/IH, 

3870. 

C'JPlb 

• 

INT  .INT/IH. 

26. 

cupmt 

• 

• 

TNT  ’jNT/IH) 

Roll, 

DISCOUMP 

• 

INT  ]inY,jh) 

2021 

OISChECK 

INT  .INT.IH. 

3076. 

OTSr I  NT 

INT  .INT.IH. 

1967, 

DISkmOI) 

TNT  .INT.IH. 

176. 

OUMPrtnT 

INT  .INT, JN, 

2035, 

EDITj? 

INT  .IMT/JN, 

525, 

FORTRAN 

INT  .INT 

N/S  . 

HASP 

INT  .iut/ih. 

6 1  Ro , 

IFTRaN 

GEN/.GR/Ih  . 

]9I8, 

PES  . 

INITSPLC 

INT  .INT/IH. 

163. 

L IBLOR 

INT  .INT/JM. 

2«7«, 

mtk 

INT  .INT/IH, 

<>263. 

OSCnpv 

INT  .INT/IN. 

1  R07  , 

purge 

IM  .IH 

107. 

SPOOlFP 

TH  .IH  . 

1053. 

5PCUPPT 

INT  .INT/IH. 

223  i. 

T£T3? 

INT  .INT/IH, 

5038 . 

TUT 

INT  .INT/IN. 

961  . 

wcS 

INT  , I  NT 

39  33, 

csaios 

• 

INT  .INT  . 

60/(7  , 

**«*«ThE 

roil°M  ART 

SYSTEM 

TO  AN“F 

AND  OFSCRIBE 

SEpa°aT 

driver 

• 

InT  .IMT/ih, 

27063. 

sys 

• 

INT  .INT/IH, 

39 1 37 , 

COPIES  DISC  PACK  CONTENTS  TO  AND  From  mag  TAPE 
SYSTEM  TEXT  editor 

GENERATES  A  PUNCH  Tape  with  BOOTSTRAP  LOADER 
ASSEMBLY  LANGUAGE  ASSEMBLER 
ASSEMBLY  LANGUAGE  MACRO  PROCESSOR 
OBJECT-LEVEL  SVSTEM  GENERATOR  for  the  lb-BIT 
PPOCESSOR 

OBJECT. LEVEL  SY5TEW  GENERATOR  FOR  THE  32-H'I 
PROCESSOR 

dumps  the  contents  of  a  disc  pack  in  hex 

CHECKS  DISC  PACK  INTEGRITY 
INITIALIZES  disc  Packs 
MODIFIES  RISC  PACK  CONTENTS 
PANIC  dump  (FOR  AFTER  SYSTEM  CRASHES) 

SYSTEM  TEXT  EDITOR 
FORTRA”'  LANGUAGE  COMPILE8 
ALLOWS  REMOTE  JOB  ENTRY 

INTERPRETER  OF  STRUCTURED  PROGRAMMING  OF 
fortran 

INITIATES  The  spool  OUEUE 
BUILDS  AN0  EDITS  LIBRARIES 
"ULTI-TERMINAL  MONITOR 
SYSTFM  COPY  ROUTINE 

ELIMINATES  OLD  FILES  FROM  a  DISC  PACK 

ALLOWS  USER  CONTROLLED  INPUT  TO  THE  SPOOL  OUEUE 

creates  and  Maintains  source  files 

CSS?  task  ESTaBLTSwep 

Task  file  Patch  routine 

WRITABLE  control  STORE  SUPPORT  soft-are 

ASSEMBLY  LFVEL  DEBUGGING  tool 


*»«»*TmF  Two  PRECEDING  LIBRARIES  CREATE  The  OPERATING  SYSTEV 

FORTRAN  ,  jnT  .  jiT/th,  23179,  PROV roE S  SUPPORT  FOR  The  FORTRAN  vi  language 
RUn-TIme  ....  -ITh  MATHEMATICAL  FUNCTION'S,  I/O  FACILITIES, 
....  A ,JP  RFAL  TIME  INTERFACES, 


t  * 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


.PATE:  28  Sept  1979 


.  16B9S7. 


cl  name 

EST 

SUP*  mainT  SOURCE 
PLIER  RES  LINES 

ADDND" 

IH 

•  • 

•  2375, 

CHK-aS 

1H 

.IH 

.  790 , 

EI.HOFP 

IH 

.IH 

.  229 , 

GENOFP 

IH 

.IH 

•  , 

INTOfP 

IH 

.IH 

•  115, 

XFILE 

IH 

.IH 

.  «. 

LSTOFP 

IH 

IlH 

•  • 

.  1211, 

ofpoata 

IH 

1  I  H 

•  • 

•  2732. 

refile 

IH 

.IH 

■  64. 

« 

•  • 

•the 

FOLLOWING  OFP  Cl 

AR7MIN 

IH 

*  I  H 

•  • 

.  JP7. 

A  R  7  n  c  U 

IH 

.’lH 

•  • 

.  JP9  . 

BINH£X 

IH 

,‘lH 

•  • 

.  207. 

BINOcT 

IH 

•  IH 

.  212, 

BINNCu 

IH 

.IH 

.  JOB. 

8  I  NPp  T 

IH 

.IH 

.  29S. 

HEXBIN 

IH 

.IH 

,  2  JO , 

MtXPpT 

IH 

.I” 

.  316, 

JULPIN 

I  H 

.IH 

.  2  J I , 

JULIAN 

IM 

.IH 

,  290 , 

OCT«in 

IH 

.IH 

•  2^7, 

PPT  T  J  T 

IH 

.  I* 

.  J97, 

RPTBIN 

IH 

!  IH 

!  job! 

PP  I  N’C  II 

IH 

.IH 

.  JOJ, 

sowt 

IM 

.  IH 

.  120j. 

TOTAI 

1J2S6.’ 

INTERDATa 

Off>  (OPERATIONAL  FLIGHT  PPQGRAM) 
UTILITY  SOFTWARE 


DESCRIPTION 


pith  a  change  cycle 


LISTING  FILE 


Converts  an  art  fqpmat  file  f0r  the  u.pi 

TO  BINARY  JN  CHAC  FORMAT 

CP«VERTS  an  art  format  file  FOR  the  N'CU  to 
TO  BINARY  in  CHAC  FORMAT 
CONVERTS  LON  [9  bits  FROM  BINARY  TO  HEX 
CONVERTS  LOh  |2  BITS  FROM  RINaRY  TO  OCTAL 
PRODUCES  NCU  PUNCH  TAPE 
PRODUCES  C"AC  PUNCH  Tape  FOR  TH£  o.pi 
CONVERTTS  Two  H£X  WORDS  To  One  binary  word 
PUNCHES  U  FRAMES  OF  TAPE  IN  P.RI  format 
Returns  oaTe  ano  time  jn  binary 
bFTUPNS  date  and  T I mf  in  ASCII 
CONVERTS  T*0  octal  WORDS  TO  binary 
punches  man. readable  punch  tape  leader  and 
TRAILER 

°E*OS  A  B.PJ  PUNCH  TAPE 
reads  a  ncu  punch  ta»e 

universal  sort  routine 


INTERDATA 

data  REDUCTION 


PREDICTIVE  SOFTWARE  DOST  MOOEL 


CONTINUATION  SHEET _ _ _ DATE:  28  Sept  l£79 


Cl  name 

sup* 

PLIES 

hajnt 

res 

ESI 

SOURCE 

LINES 

DESCRIPTION 

AC1LBL 

IN 

• 

.IH 

0  • 

.  258. 

CREATES  IBM  STANDARD  TAPE  LABELS 

AC  1 1 1ST 

IN 

.IH 

.  421 . 

LISTS  AC!  FORHAT  DATA  SETS 

ac i read 

IH 

.IH 

.  155. 

READS  AC  1  FORMAT  OR  IB*  v  FORMAT  hagn£TIC 

• 

•  0 

tape 

clform 

IN 

.IN 

.  1915. 

refophats  tspi  or  alast  pave  flight  test 

• 

•  • 

data  tape 

ENGIST 

IH 

.IN 

.  5B08. 

LISTS  THE  REFERENCE  DATA  FILE 

CENEILE 

IH 

.1" 

.  1050. 

CREATES  ca»0  IMAGE  INPUT  FOR  SMFILE 

LABEL 

IH 

.IH 

.  251. 

CREATES  IBM  STANDARD  TAPE  LAPELS 

meRCf 

IH 

.IN 

.  2585, 

HERGES  FLIGHT  TEST  DATA  AND  GROUND*B*SED 

• 

0  0 

instrumented  range  data 

PDFOU"P 

IH 

.IN 

.  220. 

LISTS  PERMANENT  DATA  FILES 

SMDUMP 

IH 

.IH 

.  2609, 

LISTS  PERHANENT  data  files 

SMtniT 

IH 

.IN 

.  5T7T. 

formats  and  tags  data  from  *  temporary  data 

• 

•  • 

FILE  TO  A  PERMANENT  data  FILE 

SMF1LE 

IH 

.IH 

.  12141. 

BUILDS  A  REFERENCE  DATA  FILE 

SMFORM 

IH 

.IH 

.  1554. 

CREATES  AN  AC  1  DATA  BASE  FRdm  a  permanent 

0 

.  . 

data  file 

smlist 

IH 

.  IH 

.  99*2. 

PROVIDES  PRINTED  REPORTS  OF  flight  TEST  data 

SHMerG 

IH 

.x* 

.  1527. 

MERGES  TWO  PERMANENT  daT*  FILES 

The  Following  O.R.  Cl'S  ARE  CONTAINED  IN  THE  GDUSFR  LIBRA# 


AOPVCS 

• 

IH 

.IH 

0 

57. 

COMBINFS  OOUBLE  PRECISION  PARITY,  VALIDITY, 

t 

0 

0 

0 

CONTROL#  AND  SPARE  BITS 

ASChex 

0 

IH 

.I” 

0 

54. 

CONVERTS  ASCII  HE* 

ABEND 

• 

IH 

.IH 

• 

!**. 

abnormal  EnDS  DUMP 

ASCINT 

0 

IH 

•  IH 

0 

s«. 

CONVERTS  FROM  ASCII  TO  BINARY  INTEGER 

ati«e 

0 

IH 

.IH 

0 

21. 

PROVIDES  tine  OF  DAY 

BCD* IN 

0 

IH 

.IH 

0 

55. 

CONVERTS  BCD  TO  BINARY 

BIT 

0 

IH 

.IH 

0 

51. 

EXTRACTS  BITS  FROM  A  HALFmORO 

BlTil 

0 

IH 

.IM 

0 

52. 

extracts  BITS  FROM  A  FULL  »ORD 

BT  I  M£ 

• 

IH 

.IH 

0 

21. 

PROVIDES  TIME  OF  DAY 

BIT* 

0 

IH 

.IH 

0 

59. 

EXTRACTS  BITS  FROM  A  DOURLE  MOPO 

coate 

0 

IH 

.IH 

0 

21. 

PROVIDES  CALENDAR  DATA 

CF6*sa 

0 

IH 

.IH 

0 

55. 

READS  FLIGHT  TfST  TAPE  ID  PECORDS 

CF  6*6  w 

0 

IH 

.I” 

0 

12. 

MOVES  data  BETWEEN  BUFFERS 

CFP*6V 

• 

IH 

.IH 

0 

15. 

CONVERTS  TIME  WORDS  FROM  JNTEGFR  TO  FLOATING 

0 

0 

0 

0 

POINT 

CFbSfcY 

0 

IH 

.IH 

0 

15. 

CONVERTS  time  WORDS  FROM  FLOATING  POINT  TO 

0 

0 

• 

0 

INTEGER 

CFbBfcZ 

0 

IH 

.1“ 

0 

109, 

reads  FLIGHT  test  data 

DUMP 

0 

IH 

.1“ 

0 

123. 

REGISTER  AND  CORE  DUMP 

FTDA 

0 

IH 

.IH 

0 

119. 

READS  ONE  FRAME  of  FLICH  TEST  DATA 

FT  ID 

0 

1« 

.IH 

0 

*2. 

DEFINES  CHANNEL  CODES  AND  READS  ID  INFORMATION 

FTIA'IT 

0 

IH 

.IH 

• 

54. 

READS  input  VALUES  AND  INITIALIZES  ARRAYS 

INTEBA 

0 

IH 

.IH 

• 

57. 

CONVERTS  integer  TO  ASCII 

INTER* 

0 

IH 

.IH 

0 

37, 

CONVERTS  INTEGFR  TO  ASCII 

InTmxa 

0 

IH 

.IN 

0 

31, 

CONVERTS  INTEGER  to  he* 

InThx* 

0 

IH 

.IH 

0 

32. 

CONVERTS  INTEGFR  TO  HEX 

KOMPaR 

$ 

IH 

,  IH 

0 

4  4, 

LOGICAL  COMPARE  *ET»FEN  Two  CHARACTER  STPJNGS 

LST«SG 

0 

IH 

.  1M 

• 

25. 

lists  MESSAGE  TO  The  OPERATOR  CONSOLE 

K  VC  HD 

0 

IH 

.IH 

• 

33. 

MOVE  CHARACTER  RFPf A T  ROUTINE 

\Zk 
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RDU"P 

1 

.1“ 

.  Rs. 

DUMPS  Pf SISTER  CONTENTS 

READ 

• 

:*• 

.1* 

.  55. 

NON.PURRERED  UNFORMATTED 

binary 

READ 

SaYTf 

• 

ih 

.1* 

.  57. 

SWAPS  BYTES  IN  POP  WOROS 

status 

. 

i“ 

!  * 

.  s5. 

OBTAINS  JOB  STATUS  INROR 

"ATION 

tplsrt 

• 

im 

,'lH 

.  Mb, 

bubble  SORT 

TRANSL 

a 

i- 

.1” 

.  72. 

CONVERTS  RRO«  EBCDIC  TO 

ASCII  AND  VISA. VERSA 

HPITt 

• 

T« 

.1“ 

.  55. 

NflN.pUFFERED  UNFORMATTED 

BINARY 

WRITE 

total 

a 

• 

■ 

• 

•  • 

,  <lb.  002, 

HARRIS  F/FE 
SYSTEM  sort  *  are 


tST 


:i  name 

SUP¬ 

PLIED 

"  A  ]  N  T 
RES 

SOURCE 

LINES 

DESCRIPTION 

ACLPmP 

h 

»  I  M/H 

!  100,’ 

UNKNOWN 

ACUTjl 

W 

.  1m/m 

.  224  0, 

ACCOUNTING  UTILITY 

atab 

»< 

.IH/N 

.  2B0. 

»EAL  TIME  program  to  ACCUMULATE  NUMBER  PR 

h 

.  I  M/M 

•  • 

SECTORS  USED  PY  EACH  USER 

3A  SL I B 

H 

.IN/W 

.  41>B0, 

BASIC  LIBRARY 

;m<iofe 

M 

.  I  M/M 

,  120. 

INITIATES  PROGRAM  V,caoF|V  To  PUT  PRINTER 

a 

•  • 

ORF  LINE 

:m«on 

I  * 

.r- 

,  100. 

INITIATES  PROGRAM  V|C4(jN|V  TO  PUT  PRIMER 

• 

.  • 

ON  LINE 

COBOL 

M 

.  H  /  I  M 

.  1160. 

COBOL  COMPILER 

JaTapOOL 

W 

,  N  /  I  H 

.  1400. 

PROCESSES  DaTa  AREAS  USED  BY  FORTRAN  COMPILER 

JISWCTEC" 

w 

,h/I“ 

.  80. 

VERIFIES  INTERNAL  LOGIC  INTEGRITY  OR  THE  DISC 

FORTRAN 

H 

.  M  /  I  W 

.  172B0. 

fortran  compiler 

JFNClIb 

*• 

.M/IH 

.  500. 

GENERATES  COBOL  library 

[RTRan 

GEN/ 

.GP/IM 

.  1 R 1 ?. 

irtran  compiler 

FF.$ 

• 

a  a 

ISL'Tu 

M 

,M/I“ 

•  «ao# 

INDEXED  SEOUfNTlAL  UTILITY  PRIMARILY  USED  FOR 

• 

•  a 

COBOL 

JOBCNTRL 

,H/IW 

.  20550 , 

interactive  user  INTERFACE  to  VULCAN 

.RE^ITOP 

,  H  /  I  M 

.  1  PRO . 

LIBRARY  RILE  EDITOR 

ysutil 

u 

,  M/  I  “ 

.  14  1, 

SDRT/mebge  utility 

3  C^BOL 

.M/IH 

.  4«0. 

ANCILLARY  phogram  USED  PY  aCOROL 

trIMTR 

H 

.M/IM 

,  380 . 

PROVIDES  OCTAL  OP  ASCII  dump  of  SELECTED 

• 

•  a 

RECORDS  OF  A  FILE 

TPt T£H 

u 

.M/IH 

•  */k  a 

HARRIS  S1IPPLIF0  SYSTEM  PATCH 

J  A  M I  A  “ 

!H 

.IN 

,  loo. 

CHECKS  A  DISC  FOR  UNUSED  AMNo  SHARED  SECTORS 

JaLTeST 

I* 

.IH 

,  10, 

EXERCISES  SCIENTIFIC  ARITHMETIC  UNJT  {SaU)  AND 

t 

•  a 

ABORTS  ON  ERROR 

r  arescrt 

H 

.M/IM 

a  WA  . 

SORTS  RECORDS  ON  TAPES 

if  st 

T* 

.IM 

.  U. 

EXERCISES  mulTIPLLICaTION  FUNCTION  OF  SaU 

h«‘,el 

M 

.M/IM 

,  1630. 

TAPE  LAPEL  PROGRAM 

YIACPYjV 

H 

.M/IM 

•  120. 

ACCOUNTING  RECORD  COPY  PROGRAM 

YtACSk'tV 

H 

.  M  /  I  M 

a  ?t>0 , 

ANCILLARY  ACCOUNTING  UTILITY 
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/:ascT|V 

M 

?0t'. 

ACCOUNTING  SECTOR  RE.  A  n  /  *►<  I  TE  SERVICE 

/ S  *  Tl  s  v 

M 

120. 

ANCILLARY  ACCOUNTING  utility 

/ :  bfh2  t  v 

H 

.H/T“ 

160. 

RL0CKED  DISC  area  hanDLER/EXTENSIOn 

/:HLaHiv 

.H/IH 

1200. 

blocked  DISC  area  handler 

/:Cua 

.  IN 

12c. 

DISCONNECTS  line  PRINTER  and  CARD  REAHfp 

4iQtiQ*lV 

M 

.in 

100. 

CONWECT5  LINE  PRINTER  AND  CARD  ®EApER 

/!CBa5»v 

H 

,H/IH 

1  <10. 

BINARY  CODED  OECIMAL  TP  ASCII  CONVERSION 

/  scr *siv 

H 

.H/IH 

2&0  , 

EBCDIC  TO  ASCII  CONVERSION 

/:Cpoh»v 

H 

.H/IH 

80o. 

CARD  Punch  handle* 

/lCP0S|V 

M 

.H/IH 

600. 

CONTROL  POINT  QUEUE  SWITCHER  PRDG°A" 

/»CPpH|V 

M 

.H/IM 

600. 

CARO  READER  handler 

/1CRPH|V 

h 

.H/IH 

1520. 

CARD  PUNCH  HANDLER 

/:C»TH|V 

h 

.H/IM 

1860. 

HARRIS  CRT  HANDLE® 

/S0'»MP  t  V 

H 

.H/JH 

280. 

POST  m0RTEH  DUMP  GENERATOR 

/  • DMMPgR | V 

M 

,  H  /  I H 

600 , 

REAL  Time  PORTION  OR  dump  program 

/SEK73JV 

IH 

.!H 

80. 

/  iGEnS i v 

M 

.H/IH 

1  800. 

SYSTEM  GENERATION  MONITOR  PROGRAM 

/ :  HE  *n  I  v 

M 

.H/IH 

360 , 

LINE  PRINTER  HEADER  PAGE  GENERATOR 

/•in*c«v 

H 

.H/IH 

2200. 

DIRECT  MEMORY  ACCESS  CONTROL  PROCESSOR  SUPPORT 

• 

MODULE 

/ 1 1'v-E  *  1  V 

H 

.H/IH 

80. 

INTERRUPT  EXECUTIVE  SERVICE 

/•nsPiv 

H 

.H/IH 

320. 

interactive  terminal  spooler  progra" 

* ( lp0H 1 V 

M 

.H/IH 

780. 

UNIVERSAL  LINE  printer  handler 

/,LplH|V 

M 

.H/IH 

1  060. 

UNIVERSAL  LINE  PRINTER  HANDLE* 

/•LPjHjV 

NK 

.H/IH 

680. 

VERSATEC  line  printer  handler 

/  j  L  °JW | V 

H 

.H/IH 

860. 

ASYNCHRONOUS  LI,JE  PRINTER  HANDLER 

<:LPcniv 

1H 

.!h 

f 

620. 

MODIFIED  LINE  PRIMER  HANDLER  FOR  GD  h£aD£R 

• 

PAGE 

/jHEmPiV 

1H 

.IH 

1200. 

CHECKS  OUT  C  PROCESSOR 

'«HESG|V 

H 

.H/IH 

680. 

MESSAGE  (SEND  RECEIVE)  SERVICE 

'iOLaYjV 

K 

,H/IH 

680. 

OVERLAV  SERVICE 

'«OPc«|V 

H 

.H/IH 

660. 

OPERATOR  COMMUNICATIONS  command  INTERPRETER 

<.OPCl|V 

M 

.H/IH 

600, 

OPERATOR  COMMUNICATION  SEGMENTS  .  EAC« 

• 

PROCESSES  ONE  OR  MORE  PPCO"  cO-manDS 

■lOPC?|V 

W 

.H/IH 

600, 

•  «  ft 

‘:opc3tv 

H 

.H/IH 

600. 

ft  ft  ft 

■sopcpiv 

H 

.H/IH 

620. 

ft  ft  ■ 

'■Opc5tv 

M 

.H/IH 

600. 

ft  ft  ft 

'iOPcfcjV 

H 

.H/IH 

620. 

ft  ft  ft 

'tOPC?  *v 

H 

.H/IH 

360. 

ft  ft  ft 

'sOPc^i  v 

M 

.H/IH 

«60. 

ft  ft  ft 

•|OPc°«V 

H 

,  H/ 1 H 

720. 

ft  ft  ft 

tOpCA|V 

M 

.H/IH 

680. 

ft  ft  ft 

J0PCB|V 

h 

.H/IH 

720. 

ft  ft  ft 

:opcc jv 

M 

.H/IH 

780, 

ft  •  ft 

fPPCOlV 

M 

.H/IH 

320. 

ft  ft  ft 

lOPcXf v 

N 

.H/IH 

SUu  , 

ft  ft  ft 

i  opc  1 1  v 

N 

.H/IH 

ItiO. 

ft  ft  ft 

| P»PH | V 

JH 

.IH 

1 656.HAMDI.EP  POP  HARRIS  EK'D  OF  INTERDATA. HARRIS  LINK 

tPlGOjV 

IH 

.IH 

200, 

NON»Rf S I DENT  HANDLER  That  PUTS  OUT  cp  header 

1 PTpH | V 

H 

,  H/  I  H 

700. 

PAPE*  Tape  punch  handle* 

'  t  P  T  RH | V 

M 

,M/JH 

380  . 

paper  Tape  READER  HANDLER 

t  PE  HH i V 

h 

.H/IH 

660. 

DISC  DIRECTORY  REHASH  SERVICE 

!»SC?|V 

w 

.H/IH 

<160, 

RESOURCE  ALLOCATION  SERVICE  -  PART  2 

:RSeX|V 

H 

.H/IH 

52(1. 

RESOURCE  DEALLOCATION  SERVICE 

JPSPC ;V 

K 

,  H  /  1  H 

1120, 

RESOUOCF  ALLOCATION  SERVICE 

,PTf  XjV 

H 

.H/IH 

80. 

REAL  time  executive  program  (USED  FDR 

• 

• 

1 

T1“EP  SCHEDULING) 
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iRTphjV 

h 

.M/IH 

«,  600 .  REAL  TIME  PERIPHERAL  HANDLE* 

iSCA^lV 

M 

.M/IM 

,  1220.  FORMAT  SCAMMER  SERVICE! 

iSERVjV 

M 

.M/IM 

,  |RS0.  BACKGROUND  SERVICES 

1  SRV2l  V 

H 

.M/IW 

,  3A0.  BACKGROUND  SERVICES 

|SYj5|V 

M 

.M/IH 

.  600.  SVSTEH  INITIALIZATION  PHASES 

|SY11,V 

h 

.H/IH 

.  700.  SVSTEH  INITIALIZATION  PHASES 

:S»12|V 

H 

.H/IM 

,  920.  SYSTEM  INITIALIZATION  PHASES 

:Svj jjv 

M 

.H/IH 

,  1000,  SYSTEM  INITIALIZATION  PHASES 

iSYlUtV 

• 

w 

.M/IH 

,  1100.  SYSTEM  INITIALIZATION  PHASES 

tTEN?|V 

H 

,m/1h 

,  J00.  PHASE  2  OP  ViTENSlV 

iTenS»v 

H 

.M/IH 

.  BOO.  5  SECOND  system  CHECK  PROGRAM 

iTlhi »v 

H 

.H/IH 

.  I960,  tape  LABELING  SERVICE 

sTLh?iV 

M 

.H/IH 

,  2JBO.  TAPE  LABELING  SERVICE 

|TLSS|V 

M 

.M/IH 

.  780,  TAPE  LABELING  SERVICE 

jTOaDjV 

M 

.H/IH 

,  1000.  REAL  TIME  SERVICES 

,T»aP|V 

u 

.M/IH 

.  620.  VULCAN  EXECUTIVE  TRAP  SERVICE  ROUTINE 

i TTYH|V 

M 

#H/IM 

.  1760.  TELETYPE  HANDLER 

jUPRG|V 

M 

.H/IH 

.  200.  USER  NUMBER  DISC  AREA  PURGE  PROGRAM 

:upuSiV 

M 

.H/IH 

,  180,  UPDATE  USER  ACCOUNTING  SERVICF 

|US£R| V 

N 

.H/IH 

.  380.  USER  NU“BEP  LOOK  UR  SERVICE 

lUSPClV 

H 

.H/IH 

,  200,  DISC  SPACE  DEALLOCATION  SERVICE 

aSSem 

* 

.M/IH 

,  9080.  ASSEMBLY  language  PROCESSOR 

BASIC 

.H/IH 

,  0020.  BASIC  PROCESSOR 

ILCa«O0 

I  H 

.IH 

,  1 8990 ,  DISC  COPY  OP  RESIDENT  VULCAN  THAT  IS  PUT  INTO 

• 

• 

,  ,  MEMORY 

ulcaniz 

IM 

•  IM 

,  200.  CREATES  LOAD  MODULES 

bee 

w 

.M/IH 

.  2060.  CPOSS  REFERENCE  PROCESSOR 

IBERY 

H 

.H/IH 

.120800.  HARRIS  SYSTEM  LIBRARY 

«CASS,V 

M 

.H/IH 

,  1620,  CASSETTE  HANDLER 

ORP 

IM 

.IM 

.  10.  EXERCISES  exponentiation  function  in  sal1 

lETciV 

IH 

•  IM 

,  120.  NON.RESIDENT  HANDLER  POP  OBTAINING  CONTENTS 

• 

.  .  ON  memory  SYSTEM  ID,  and  DAY  op  The  NfEK 

:UadR i v 

IM 

.IH 

,  100.  ABSOLUTE  DISC  READS  FOR  USER  ROUTINES 

(PMO 

• 

H 

.H/IH 

,  1980.  ROST  MORTEM  DUMP 

TOTAL 

• 

• 

• 

• 

! 2*2953) 

HARRIS  P/FB 

UTILITY  SOFTWARE 

EST 

SUP* 

VAIW7 

SOURCE 

I  -i»*'E 

PI  Iff 

RE  S 

LINES  INSCRIPTION 

.IM 

IM  . 

103  CONVERTS  NUMBER  TO/FROM  INTEGER,  OCTAL,  HEX, 

.  ,  ASCI!  AND  TiSCII 

nMPi»^E 

1“ 

.IH 

,  BIS,  FLOATING  POINT  CALCULATOR 

OPVTEPF 

• 

I  M 

.1“ 

»  200,  CORIES  ONE  MAG  TAPE  TO  ANOTHER 

c 

• 

I  M 

.IM 

.  60.  DISPLAYS  SELECTED  LOCATIONS  OF  CORE 

F 

IM 

.1“ 

»  n/s  ,  displays  mappjhg  information  for  a  file 

L  A  p 

■ 

1“ 

.IM 

,  260,  ELIMINATES  FILES  It.  A  MAP  OUTPUT 

L  y  ‘  -6  VE  B 

IM 

.1“ 

.  260,  ELIMINATED  FILFS  In  AVERTFV  OUTPUT 

"T-'r 

t 

I" 

.1" 

,  1«0, CORIES  DATA  FPDM  hr  TAPE  CaSSFTTE  TO  DISC  FILE 

"TSuapj 

• 

1“ 

.IM 

,  65,  SPOOL  S  SNAPSHOT  OF  CRT  SCREE*  TO  PRINTER 

wpmptciv 
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ENCMfj 

.IM 

,  1«7,  GENERATES  command  file  USED  IN  aTCDPY? 

PCD 

.  IM 

•  IM 

• 

.  N/S 

,  GENERAL  PURPOSE  COPT  ROUTINE  TO  SUPPPF!  CAR- 
.  TR70GE  on  HP  TERMINAL 

FfcPC* 

.  IH 

.IM 

.  3Sa .  OUTPUTS  FORMATTED  LIST  OF  FILES  ON  A  KEEPTaPE 

,  TO  THE  PRINTER  AND  VERIFIES  THE  TAPE 

F 

.  I” 

.IM 

bb  , 

COMPARES  2  FILES 

PC^PV 

_ T  H 

t  u 

200, 

COPIES  A  MAG  TAPE  IN  KFEP/FETCH  FORMAT  TO 

• 

ANOTHER  MAG  TAPE 

M 

.  IM 

.  IM 

?bb« 

PROVIDES  A  LIST  OF  hmich  LFN'S  ARE  CURRENTLV 

• 

ASSIGNED  FROh  INTERACTIVE  TERMINAL 

E-USER 

8  H 

.H/IH 

*0, 

CHANGES  QUALIFIER  AND/OR  USER  nu«BFR  OF  FILES 

AKCH* 

,  IM 

.IM 

LISTS  FILES  “HICH  HAVE  NOT  BEEW  ACCESSED 

SINCE  The  ENTERED  CUTOFF  DATE 

E  ADF  JLF 

.  IM 

.IM 

10f  0. 

READS  FILE  INTO  AN  OUTPUT  FILE  ADDING  PAGE 

» 

NUMBERS  and  CARRIAGE  CONTROL  FOR  SPOOLING 

TO  THE  PRINTER 

FETCh 

»  tH 

.IM 

220. 

CONSTRUCTS  A  JOB  STREA-  TO  FETCH  SELECTEO 

FILES  FROM  A  TAPE 

N*piT 

.  IM 

.IM 

CO, 

SNAPSHOTS  THE  CONTFNTS  OF  a  TEC-025  SCREEN 

COPY? 

,  IM 

.  IM 

1132. 

P£Af>/MRIT£  F°Om  DISC  TO  TaPE  and  VISA-V£R5a 

F 

.  IM 

.IM 

16257. 

TE*T  EDITOR 

hP'jhS 

,  IM 

.IM 

600. 

TRANSFERS  FILES  BETMEEN  PROCESSORS  THROUGH 

HIGH  SPEED  memory 

PECPT 

.  IM 

.IM 

RO, 

HAKES  DIRECT  BINARY  COPY  FRO"  tape  TO  TaPE 

URNpO 

.  I” 

.  IM 

00, 

rotates  PRINTER  OUTPUT  10  DEC, 

yrff 

,  I1" 

.IM 

200. 

PRODUCES  VARIABLE  and  FILE  NAME  CROSS  R£FERENCF 

FRO**  an  ALPHABETIZED  LIST  OF  VARIABLES  AND 

• 

FILES 

the 

.  IM 

.IM 

200. 

ALLOWS  USER  To  WRITE  TO  TAPE  CARTRIDGE  U> 

HP  TERMINAL 

.  I” 

.IM 

ISO. 

SEOUENCES  SOURCE  FILFS 

*NM| 

,  IM 

.IM 

•  50. 

UNPACK  aREAName  from  TRUNCATED  ASCII  (aCPW) 

• 

TD  STANDARD  ASCII  (1CPW) 

TNMJ 

,  IM 

.IM 

.  30. 

UNPACK  AREANAME  from.  TRUNCATED  ASCII  (UCR-1 

TC  STANDARD  ASCII  (3CPw) 

iSLPPKi 

.  I” 

.IM 

ASSIGN  LFN  (NON  RESOUHCABLE  PpMI$  ONLY) 

SLCaS 

.  IM 

.IM 

.  55. 

ASSIGN  LFN  TO  CASSFTTE  TAPE  On  Ti  73  3 

3LDA 

,  IM 

.IM 

.  ’ft. 

ASSIGN  LFN  TD  Disc  ARE*  (FILENAME  AND  OUalI- 

4 

FIEP  REQUIRED) 

aSLd*S 

,  I” 

.IM 

ASSIGN  LFN  TO  DISC  AREA  (QUALIFIER  DEFAULTS 

• 

TO  SIGN-ON  QUALIFIER) 

5LINF 

,  T  M 

.1* 

•  *b. 

ASSIGN  LFN  TO  ANOTHER  LFN  (FIRST  lfN  ASSIGNMENT 

FOLLOWS  SECOND) 

ASL  i »•» 

.  I  M 

.1*' 

ASSIGN  LFN  TO  ANOTHER  LFN  (FIRST  LFN  ASSlGNI'EN 

• 

DOES  NOT  FOLLOW  SECOND) 

30p  T  1 

.  IM 

.IM 

,  102. 

ALPHAMERIC  SORT  ON  an  ARRAY  in  standard 

ASCII  (1CPW) 

30PTJ 

.  IM 

.IM 

.  2J«. 

ALPHANUMERIC  SORT  ON  AN  ARRaV  IK  STANOARh 

ASCII  (JCPW) 

1  TnAJ 

.  I” 

.IM 

.  62, 

rONVFRT  STANDARD  ASCII  CICPw)  TO  STANDARD 

• 

•  • 

ASCII  (JCPW) 

l  rnfu 

.  I” 

.IM 

.  To, 

rONVFRT  STANDAPD  ASCII  ( l Cpw )  TO  TRUNCATED 

ASCII  (RCPw) 

STn»  i 

.  I” 

.IM 

.  55, 

CONVERT  STANDARD  ASCII  (5Cp«)  T'q  STa-DAR'* 

,  ASCII  (1CP») 
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STuTJ 

• 

i- 

.1“ 

"S. 

CONVERT  STANOAPp  ASCII  (3CP«)  to  TRUNCATED 

• 

a 

ASCII  (4CPH) 

I  NHf  y 

• 

Ih 

!ih 

*5. 

BINARY  TO  he  y 

pvPPT 

• 

I« 

.IH 

200, 

BINARY  TO  PUNCH  PAPER  TAPE 

• 

I* 

.IH 

6  0* 

CONVERT  BINARY  (1  WORD)  TO  HE*  (ASCII  1CP") 

nriMj 

s 

TH 

.1“ 

65. 

CONVERT  BINARY  (I  HORO)  TO  HE*  (ASCII  3Co»  ) 

• 

IH 

.IH 

60, 

CHECK  LEN  ASSIGNMENT  STATUS  AND  OBTAIN  ASSIGN. 

a 

a 

a 

MENT  INFORMATION 

,UC8» 

• 

IH 

.IH 

45. 

CONVERTS  BINARY  TO  ASCII 

.U I  p 

0 

IH 

.IH 

287. 

LONG  rORH  OF  STANDARD  call  FOR  I/O  SERVICE 

3L"J0a 

• 

IH 

.IH 

a 

CALL  FOR  I/O  SERVICE  TO  RETURN  CONTENTS  OF 

• 

a 

a 

A. register  after  I/O 

JLUIOC 

• 

IH 

.IH 

a 

CALL  FOR  I/O  SERVICE  FOR  CHaPaCTER  I/O 

3LUI0£ 

• 

IH 

.  IH 

a 

CALL  FOR  I/O  SERVICE  TO  RETURN  CONTENTS  OF 

• 

* 

a 

E-RFGISTER  AFTER  I/O 

IL'.'IOS 

a 

IH 

.IH 

a 

SHORT  FORM  OF  STANDARD  CALL  FOR  I/O  SERVICE 

JUl'I  OK 

a 

IH 

.IH 

a 

LONG  FORM  OF  STANDARD  CALL  FOR  I/O  SERVICE 

• 

a 

a 

REQUESTING  A  BAIT  AFTERWARDS 

.ULFN 

• 

Th 

•  Iw 

42. 

CHFC*  LFN  ASSIGNMENT  STATUS 

.UPpN 

a 

IH 

al* 

35. 

CHECK  PDN  CHARACTERISTICS 

/HXRl 

a 

IH 

,I« 

06, 

CONVERT  HE*  (ASCII)  TO  BINARY  (]  MORD ) 

/  Sysp 

• 

IH 

,1* 

BO. 

CONVERT  SYSTEM  DATE/T I “E  IN  ITIME  FORMAT 

• 

a 

a 

TO  ASCII  (MILITARY  FORMAT) 

ite 

a 

IH 

.IH 

«2. 

OBTAIN  CURRENT  DATE  AND  TIM£  FROM  SYSTEM 

t  n  P  o  1 

• 

IH 

.IH 

205. 

08TAIN  LIMITED  INFORMATION  ON  A  SPECIFIC 

• 

a 

a 

DISC  PILE 

3INF0? 

• 

IH 

.IH 

a 

obtain  moderatf  amount  of  information  on  a 

a 

a 

a 

SPECIFIC  DISC  FILE 

a 

IH 

.IH 

a 

OBTAIN  COMPLETE  INFORMATION  on  A  SPECIFIC 

• 

a 

a 

DISC  FILE 

fTgBI 

• 

IH 

.IH 

223. 

SCANS  AND  CONVERTS  ASCII  DATE/TJmE  (Mjl  OR 

• 

a 

a 

JULIAN  FORMAT)  TO  BINARY 

(ASf 

• 

IH 

.I” 

75. 

CLEAR  TERMINAL  SCREEN 

,"‘N8 

• 

IH 

.IH 

78. 

ELIMINATE  A  SPECIFIC  DISC  file  (OUALIFIER  »np 

a 

a 

a 

FILENAME  REQUIRED) 

;L“N*S 

a 

IH 

.IH 

a 

ELIMINATE  A  SPECIFIC  DISC  file  (SIGN-ON) 

• 

a 

a 

QUALIFIER  AS5UMED) 

pocN 

a 

IH 

.1- 

170, 

FIND  OCCURRENCE  OF  CHARACTER  IN  CHARACTER 

• 

a 

a 

STRING  FROM  A  GIVFN  ORFSET 

(NOT* 

• 

IH 

.IH 

224. 

FIND  OCCURRENCE  OF  a  CHARACTER  STRING  IN  A 

• 

a 

a 

LARGE*  STRING 

tp 

• 

IH 

.IH 

382, 

COwvfrt  ascii  representation  of  a  floating 

a 

a 

a 

POINT  TO  INTERNAL  FLOATING  POINT  RORmaT 

.GBIT 

a 

IH 

.  IH 

AO. 

SET  A  SPECIFIED  BIT  IN  AN  ARRAY 

<Tl»T 

a 

IH 

.IH 

165, 

FORMAT  latitude/longitude  INTO  ASCII 

(Tlon 

a 

IH 

.IH 

a 

format  LATITUDE/LONGITURI)  into  ASCII 

istCm 

a 

IH 

.IH 

92, 

find  FIRST  NONBLANK  CHARACTER  JN  A  CHARacTFR 

a 

a 

a 

STRING 

ICAN 

a 

IH 

.IH 

265. 

CALL  TO  SYSTEM  format  SCANNER  SERVICF 

r  n  n  ^ 

a 

IH 

.IH 

165. 

GENERATE  A  DISC  RILE  NlTn  ACCOUNT  ACCESS 

a 

a 

• 

(SHORT  PORm) 

v*i 

a 

IH 

.IM 

a 

GENERATE  A  DISC  FJIE  (LONG  FORM) 

JVf/p 

a 

IH 

.  IH 

a 

GENERATE  A  disc  file  WITH  Onner  ACCESS  Only 

a 

a 

a 

(SHORT  FOR") 

f  r,f.p 

a 

IH 

•  IH 

a 

GENERATE  A  DISC  FJLE  *1Th  PU*LIC  ACCESS 

a 

a 

a 

(SHORT  FORM) 

l  x  p  i  n 

a 

In 

,i» 

1*0. 

CONVERT  ME*  TO  BINARY 

;  *  1  n 

a 

IH 

,  I  M 

9<i, 

INPUT  A  NO  CONVFKT  HE*  ASCII  (UP  TO  8  CHARACTERS 
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TO  »1>  ARY  1 1  »DRn) 

rxopT 

I  - 

!  if 

164. 

DATA  [In  he*)  TO  PUNCH  P  4  PR  p  7  APR 

5JRT  3 

T* 

.  IH 

46, 

Hf*  SCPT  ON  ASCII  REPRESENTATION  OP  hr» 

• 

MUMPERS  In  an  APPAY 

l  TOal 

I « 

.1- 

Pi'. 

CONVERT  HEX  [ASCII  1CPH)  TO  BINARY  [1  *UR0) 

)PK 

I* 

.1“ 

45. 

OBTAIN  PROGRAM  OPTION'S  FR0“  program  opticn 

• 

“ORO  PROH  INITIALIZATION 

J  L 0  x 

I« 

.  IX 

another  entry  point  fop  frstch 

JLIaN 

I« 

.IP 

1  is! 

CONVERT  return  FR0“  SYSTEM  $  T I  hr  SERVICE  TO 

• 

JUL I A  k  FORM  date  ANO  TI“E 

fPyp  j 

IH 

.IM 

60  . 

CONVERT  A  HARRIS  FLOATING  PONT  number  to  uPI 

• 

FIXED  POINT  Niimrep 

)MP4R 

IH 

.1W 

122.' 

COMPARE  CHARACTER  STRINGS 

kSTC« 

1  M 

.IM 

4J. 

find  Last  NONBLAMK  CHARACTERS  IN  a  CHARACTER 

• 

STRING 

(STING 

Ih 

.IP 

332! 

COPY  FILE  TO  FILE  PITH  PRINTER  SPACING 

>Tnrk 

IH 

.IP 

ANOTHER  ENTRY  POINT  FOR  LASTCh 

JVCS® 

1  H 

.IP 

S2! 

“OVE  CURSOR  ON  THE  TEKTRONIX  4014 

/Chr 

TH 

.IP 

100. 

HOVE  DATA  IN  an  ARRAY 

'PARC 

!m 

.IP 

75. 

Scan  ofp  ChanGE/PROBLEm  DESCRIPTION 

;hrtu 

Ih 

•  IP 

65. 

truncate  and  insert  ascii  character  in  a 

• 

TRUNCATED  ASCII  ARRAY  («CRm) 

JMPPT 

1  H 

.IP 

44, 

obtain  program  OPTION'S  AND  PARAMETERS  AT 

• 

PROGRAM  INITIALIZATION 

■TluR 

T  H 

.I” 

63*. 

PUNCH  PAPER  Tape  LEADER 

*  T  T  J  T 

JH 

.IP 

35. 

punch  paper  TPaE  TITLE 

fC>l»R 

Ih 

.IP 

147. 

CONVERT  ASCII  CHARACTER  To  PapfR  TAPF  COPE 

fN4«E 

Ih 

.IP 

*6. 

bena«e  a  pise  file  to  a  ner  name  (qualifier 

• 

AND  FILENAME  REQUIRED) 

In 

.IP 

Rfna"E  a  DISC  FILE  To  a  N£ n  na“E  (SJGN.On) 

• 

QUALIFIER  ASSUMED) 

;TYpf 

IH 

.  JH 

1 00  * 

RETypE  A  0ISC  file  TO  a  ner  tv»e  GPECIficaTIun 

• 

(LONG  FORM) 

IET  VPS 

IH 

.IP 

retype  a  disc  file  to  a  ner  type  specification 

• 

(SHORT  FORM) 

»TP  J  N 

IH 

.IP 

144, 

READ  PAPER  TPAE  and  CONVERT  to  binary 

•Inf  * 

IH 

.IP 

I  7«, 

READ  PAPER  TPAE  AND  CONVERT  TO  HEX 

lose 

TH 

.I” 

65. 

RFSOURSE  DTSC  PACK 

(SOSCT 

IH 

.IP 

TEST  DISC  RESOURCE  REQUEST 

tsnsc« 

I  H 

.IP 

SPECIFY  a  RaIT  UNTIL  RESOURCE  REQUEST  for  DISC 

• 

PAC*  has  been  fulfilled 

1 H  S  4" 

IH 

.IP 

75! 

RESOURCE  high  SPEED  memory 

ISmSmT 

IH 

.IP 

TEST  HIGH  SPEED  “EMORY  REQUEST 

IH 

.IP 

SPECIFY  A  Ra l T  UNTIL  RESOUCE  REQUEST  F HR 

• 

HIGH  SPEED  “EMORY  FULFILLED 

irTL 

I« 

.IP 

1  05.’ 

resource  mag  tape  (long  form) 

»S“TLT 

IH 

.IP 

TE5T  mag  tape  RESOURCE  REOUFST  tLO,JG  form) 

1 S  M  T  l_  *“ 

IH 

.IP 

SPECIFY  A  RAIT  UNTIL  RESOURCE  REQUEST  FOR 

. 

mag  tape  has  been  fulfilled 

JmTs 

TH 

.IP 

*6  ! 

R'ESOURct  MAG  Tape  (SHORT  FORM) 

(SmtST 

1  H 

.I” 

TEST  mag  tape  RESOURCE  REQUEST  (LONG  form) 

*SMTSw 

IH 

.1“ 

SPECIFY  a  RAIT  U'lTTL  RESOURCE  PEMUEST  F OP  MAG 

. 

TARE  “AS  BEEN  FULFILLED 

IRON 

IH 

.1" 

Eft, 

Resource  pdn  (must  be  resourceable) 

?SP(|NT 

IH 

.IP 

TEST  PON  RESOURCE  REDOES* 

ISPp«-4 

IH 

.1“ 

SPECIFY  A  yait  until  RT SOURCE  REQUEST  fop  °tu. 

• 

HAS  BEEN  FULFILLED 

J  T  H  I  T 

IH 

.IM 

51  ! 

set  PIT  IN  A  VECTOP  ARFAY 

I 
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)RT 

12 

.  tH 
.  IH 

.1“ 

,  IH 

•  90, 

•  62  • 

BI'iAPY  STRT  DM  AM  ARP  A  V  RY  RO* 

SQUEEZE  BLOCKED  DISC  FILF  70  min. 

REQUIRE*"LNT 

iU7u« 

.  IH 

.IH 

•  • 

SQUEEZE  AN  UNBLOCKEO  MSC  HLE 

TO 

H  I  N  I  h'  L.1  H 

iTVAl 

• 

.  IH 

• 

,IH 

•  • 

REQUIRE“ENTS 

CONVERT  TRUNCATED  ASCII  C u P C »' J 

TO 

STANDAPC 

1 T  t!  A  3 

!  I H 

IH 

•  • 

•  «7 , 

ASCII  (ICPw) 

rONVERT  TRUNCATED  ASCII  (MCPH) 

TO 

STANDARD 

)T*L 

• 

• 

• 

■ 

• 

• 

•  • 

!  3<U94, 

ASCII  C3CPW) 

hapris  f/fb 

RJE  TRfMOTE  JOB  CONTROL )  SOF TwaRE 
fcST 


:  nA“e 

SUP¬ 

PLIED 

MaIMT 

res 

S0U»CE 

LINES 

DESCRIPTION 

:/hasp 

• 

M 

1h/IH 

3220 ! 

SPOOLER  EOR  RJE 

;NnfR 

.  ID 

.ID 

10, 

SCANS  RJE  FILE  AND  WRITES  A  LIST  OF  CRITICAL 

■ 

ft 

• 

WARNING  or  errors 

'C.RJE 

ft  H 

.H/IH 

160. 

OPCOW  RJE  DRIVER 

IE 

M 

.H/IH 

looo. 

remote  job  entry  rpucessdr 

IE»T? 

.  IH 

.1“ 

1S00, 

writes  a  list  format  RJE  DATA  FILE  TO  MAC.  TA»e 

a 

ft 

ft 

FOR  LISTING  OR  MICROFICHE 

IEGEN 

#  H 

.H/IH 

560. 

PARAHETER  GENERATION  PROD.Rah  USED  IN  CONFIGUR¬ 

• 

ft 

ft 

ING  the  IBM  SITES  INITIATED  BY  *RJE 

:  BE  RT  j  V 

t  H 

.H/IH 

ISO, 

RJE  UTILITY 

:RJEh|V 

#  H 

.H/IH 

RSO . 

REMOTE  JOB  ENTRY  HANDLE* 

it»l 

• 

ft 

ft 

ft 

Tuioj 

HARRIS  F/FB 
PLOTTER  SOFTWARE 

FST 

SUP*  haimT  SOURCE 


I  FILE 

rlier 

RES 

LINES 

DESCRIPTION 

iTBETbL 

IH 

!lw 

ft 

A;)  0, 

DATA  RETRIEVAL  PLOTTING  PROGRAM 

'PLOT 

.  IH 

.  I  H 

160. 

• 

plots  weapon  scoring  rfleases  produced 
•SCORE 

BY 

•LOT 

H 

.H/IH 

I960. 

VERSATEC  PLOTTER  routine 

.0TL1B 

M 

.  H  /  I  H 

<1460. 

VF°SATFC  PLOTTER  LIBRARY 

1PI  OT 

1TAL 

.  IH 

.IH 

200, 

• 

75Po! 

RERU'TS  OR  ELIMINATES  AREAS  CREATED  B Y 
•SCORE,  KFEP  OPTION 

USING 
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HARRIS  F/F B 
OFP  SOFTkape 


:  hare 

$HPm  HA | MT 
PL1E*<  «ES 

EST 

SOURCE 

LINES 

description 

# 

.  i* 

.ip 

36o| 

CONVERTS  «PI  Format  TO/From  ENGINEERING  values 

.  ip 

.ip 

500  . 

ELIMINATES  documentation  files  for  ofp 

jwnp? 

.  iH 

.ip 

680  . 

GENERATES  OOCUMENTATIDN  files  for  OFP 

iiorp 

.  ip 

.ip 

1780, 

LISTS  DOCUMENTATION  FILES  FOR  OFP 

’P 

.  ip 

.ip 

680. 

READS  AN  OFR  FROM  PAPER  Tape  and  FORMATS  it 

• 

• 

. 

ON  DISC  JN  CMAC  LOAD  FORMAT 

ITAL 

• 

• 

• 

• 

uooo. 

HARRIS  F/FB 
APAGE  SOFTWARE 


:  n*-e 

SUP¬ 

PLIED 

«a!NT 

»fs 

SOURCE 

lines 

DESCRIPTION 

;pp 

• 

.  I” 

•  • 
.IP 

?806 ! 

ADAGE 

DIAGNOSTICS 

IaRhIc 

.  ,H 

.IP 

<(80. 

ADAGE 

Interface  utility 

hSgS  i  v 

.  IP 

.IP 

80. 

ADAGE 

diagnostic 

p-mS  |  v 

.  IP 

.IP 

380  , 

ADAGE 

MONITOR  SERVICE 

:n? 

.  IP 

.IP 

1  ORB, 

HOST 

COMPUTER  INTERFACE  TEST 

;>Ln 

.  I” 

.IP 

1919, 

LOADS 

Test  patterns  on  adage 

IT‘L 

* 

• 

»  • 

•  1 

671«! 

HARRIS  F/FB 
S A S  SOFTWARE 


FST 

>-aIM  SOURCE 
°FS  LlwES 


nrsrRiPTir.N 
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:ag 

ip 

.IH 

.  1“0. 

SAS  DIAGNOSTICS 

ISAS 

IH 

.1“ 

.  100. 

PSEUDO  REAL  TIME  PROGRAM  USED  BY  »SaSIQ 

vSIO 

In 

.IH 

.  7UO. 

ALLOWS  The  usep  TO  SET  and  MONITOR  simulation 

• 

variables 

}!N$7|V 

3  M 

.IH 

.  20. 

OUTPUT  test  INSTRUCTIONS  AND  DATA  FROM  c 

• 

PROCESSOR  SWITCHES  TO  SAS 

;P»lS|V 

IH 

.  IH 

.  SO. 

INITIALIZES  AND  LOADS  DATA  INTO  ANY  ONF  of 

• 

•  • 

IN  SAS  FROM  c  PROCESSOR 

iSFHTfV 

IH 

.IH 

.  «  o  o , 

SAS  DIAGNOSTICS 

lS»SP«V 

IH 

•  IH 

.  moo. 

C  PROCESSOR  PROGRAM  that  DOES  I/O  Fo°  The 

SIMULATOR 

:T6«S|V 

IH 

.IH 

•  <18. 

CHECKS  OUT  CLOCK 

itai 

• 

• 

!  2688 ! 

HARRIS  F/FB 

SI"ULATo»  SOFTFARE 

EST 

SUP- 

h*JN1 

SOURCE 

:  (‘a“£ 

plied 

R£S 

LIKES 

DESCRIPTION 

IRS 

IH 

f 

.  IH 

•  • 

.  216. 

GENERATES  address  anD  CROSS  REFERENCE  INFORM*- 

TION  FOR  MONITOR  COMMON  VARIABLES 

ILL  TS 

IH 

.  IH 

.  500, 

COMPUTES  BALLISTIC  CURVES 

<F» 

IH 

.IH 

.  200. 

LOADS  C  PROCESSOR 

|TRET 

IH 

.IH 

.  2BB0, 

RETRIEVES  SIMULATION  o*Ta 

|TRETQn 

IH 

.IH 

.  iso. 

quick  and  pjrty  data  retrieval  program 

ispec 

IH 

.IH 

.  2200. 

SETS  up  data  RECORDING  file 

i 

IH 

.IH 

•  80. 

FUNCTION  WORD  ASSEMBLER 

»S“LG 

IH 

.IH 

,  160, 

KEEP  and  fetch  aSTmlog  ON  Tape 

INTTOR 

IH 

.IH 

.  1«0. 

monitors  memory  locations  anP  REPORT 5  ANY 

•  • 

CHANGES  IN  VALUF 

.AN 

IH 

.1“ 

.  "320. 

MISSION  planning  PROGRAM 

.A-MITJL 

IH 

,1H 

.  IAR0, 

PLANNING  FILE  UTILITY  program 

•t.LPJS 

IH 

.  I” 

.  20, 

RESIDENT  REAL  time  LOADER  FOR  * V i LD35 ! V 

;0»f 

IH 

.IH 

.  SCO, 

computes  the  Impact  point  of  simulation  feapon 

RELEASES 

•»  UL 

IH 

.IH 

,  100, 

MONITORS  simulation  SERIAL  data  WORD  COUNTS 

•ToaT 

TM 

.IH 

.  030. 

PUTS  A  KNOWN  VALUE  IN  MONITOR  COmhPn 

1 

IH 

.IH 

.  20u, 

initiates  the  start  of  simulation 

•UATF 

I* 

.  IH 

.  220  , 

UPDATES  MONITOP  common  DISC  fjl£S  USED  BY  The 

simulation  DISPLAY  program$ 

|  A  "  P  S  i  V 

IH 

.IH 

•  *0. 

COMPUTES  SEMI-CONDUCTOR  memory  LOCATION  OF 

MONITOR  COMMpKj  VARIABLES 

lCLt'R|V 

1  H 

,  I  P 

.  200, 

LOADS  A  PROGRAM  TN  C  PROCESSOR  FRO1'  EITHER 

A  OR  B  PRDCESSOP 

:lR7oiV 

T  H 

,  IH 

.  20  J, 

plTERRUP  hanolFR  FOR  simulator  SOFT-aRE  on 

a  PROCESSOR 

|L0J5«V 

IH 

,  IH 

,  flu. 

SETS  UPMONJTOR  SERVICE  8L  U35  FOR  NON. RESIDE'- T 

HANDLE*  *V*ETC|V 

iSpcaiv 

TH 

,  IH 

.  500, 

sets  up  “0‘ITOR  SERVICE  FLU36  ON  A  PRrrESSOR 

|S(’CPlv 

.IV 

.  7  (•  0  , 

SE.TS  1»P  •'ONITpc  SRPVTCF  PL"16  on  r  PROCESSOR 

rt*s'.Ap 

IH 

.IH 

•  t  no. 

PPODFCES  FOPMATTEO  LISTING  of  all  SIMULATION 
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CPMm*p..[>s 

!  h 

lIH 

.  U'O. 

DESCnse$  ‘•■CAPON  pRUP$  BY  Th£  5IhULaTCR 

?ETQ 

I  H 

.  IH 

.  2"0. 

PROVIDES  A  LISTING  OF  SIMULATION  MONITOR 

• 

COMMON  VARIABLES  in  PILE 

ItFUP 

IK 

• 

.  7(.0, 

LfPOATES  CROSS»PEF  vp^ENCE  FILES  JSEO  BY 

• 

•CNACRETv  ANO  *Fh 

*  P  L  A  N 

1  M 

» 

.  ShO. 

RESTRUCTURES  planning  files  to  the  Nf h  b  OFFStT 

• 

<■ 

PLANTS 

:'*l 

7 

.  ; 7 1 oe , 

h; 

CmaC  SOFTwa^F 


sin5*  source 

f*LieO  *£$  LINES  DESCRIPTION 


.  -iL'ir 

■ 

I 

.IK 

• 

3HC. 

CREATES  Chat  loik  EQK  F/Eb  ASTRO 

,oc<s 

IH 

,  IH 

?0, 

CHECKS  CLOCKS  0*.  CU4C 

.OCKT 

1* 

.1- 

1  ou. 

PE  AOS  THE  CLOCK  F=ph  tLL  j  CHAC 1 S 

•*acdI  t.r. 

T  M 

.IK 

0  0  ti  l»  , 

CHIC  DJaGi.OSITJCS 

«  A  o ;;  £  •;  V 

in 

.IK 

retrieves  r*  ..c  da-a 

'  UTCST 

IH 

.  I  H 

ROC 0 . 

ALLO‘5  USEP  TO  CPf -MUNiCATt  WITH  Cmac 

KACTI Mr 

IH 

.IK 

160, 

COHVEPTS  CMAC  COARSE  A ‘ID  EOF. 

J  M  T  P 

I-. 

.IK 

1O0, 

nuMPS  I'KAC  RECORD;  'CC 

■ 

IH 

.IK 

isa. 

CM4C  data  retrieval  proGRak  kcih  RETRIEVJ'.’G 

FULL  SNAPSHC15 

:  C  -  C  i  v 

IH 

.IK 

1  7  0  0  . 

SETS  up  "ONI  10'-'  SERVICE  FLUj«  TOP  COmmum  C  a  T  j  Ok 
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PREDICTIVE  SOFTWARE  COST  MOO  EL 


CONTINUATION  SHEET _ DATE:  28  Sept  1979 


ip 

.  PEC 

.  PEC 

.  u/5  . 

FILE  UTILITY  Package  VP8-02A 

PIT 

.  DEC 

,  PFC 

.  N/A  . 

TEET  EP1TOP  VO 06 a 

OWTttAN 

.  DEC 

.  DEC 

.  u/s  . 

FORTRAN  COMPILER  V004A 

4CP0 

.  "EC 

.  PEC 

.  K/S  . 

ASSEMBLER  VP05-01A 

I  RP 

.  PEC 

.  DEC 

.  U/S  , 

LIBRARIAN  V004A 

INK 

.  PEC 

.  PEC 

.  u/s  , 

LINKER  VI 1  AO  1 

PT 

.  PEC 

.  PEC 

.  U'S  . 

DEBUGGING  PROGRAM 

ILC0“ 

.  DEC 

.  DEC 

.  N/S  . 

FILE  COMPARE  PROGRAM  V02-04 

ILDmP 

.  DEC 

.  PEC 

.  n/a  . 

FILE  DUMP  UTILITY  VOOT* 

£R!ey 

.  DEC 

.  PEC 

.  M/S  . 

VERIFICATION  PROGRAM  V002-« 

Ill'S 

.  PEC 

.  PEC 

.  M/S  . 

CORE  IMAGE  LIB  update  AND  SAVE  VAOa 

oiti'-1 

.  PEC 

.  PEC 

.  M/S  . 

UTILITY  TO  SAVE  DISK 

vsion 

.  PEC 

.  PEC 

.  N/S  . 

SYSTfK  loader  VOOSA 

P51D* 

.  PEC 

.  PEC 

.  M/S  . 

ABSOLUTE  LOADER  V006A 

ppp  11/ao 

PT I IT T V  SPF T w APE 

EST 

S'JP- 

“AIT 
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DESCRIPTION 
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!  7m 
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.  Iw 

.  IH 

.  !05. 

TAPE  TO  TAPE  COPY 

T  0 

.  i“ 

.  Th 

.  226. 

GENERAL  Tape  PRINT 

ABELS 

,  i* 

.  Ik 

.  5J. 

PLOTS  gu  VFRTICAL  labels  FOR  TAPES 

rT 

.  IK 

•  IH 

.  «2T. 

CREATES  MICROFICHE  or  other  machine  COmPaTabLF 

tape,  LRECL  136  PR  80,  ASCII  OR  EBCDIC 
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.  1“ 

.  IH 

.  a  388, 

SUBROUTINE  LIBRARY 

PL  T  p 
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.  M/S  , 
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0  T  A  l 

• 

• 

• 

t 

!  5*  77  I 

POP  11/40 

data  REDUCTION  SOFTWARE 

EST 

SIJP- 

M  A  I  T 

SOURCE 
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s 

LIMES 

DESCRIPTION 

ALLIP 

t 

.  Ik 

•  iH 

1I?p! 

BUILD  AND  UPDATE  CALIBRATION  LIBRAi-y 

ALLS  T 

.  IK 

.  7h 

.  lap. 

LIST  CALIBRATION  LIBRARY 

"IT  Up 

.  1“ 

•  IH 

.  238 , 

DISCRIMINATOR  LINEARITY  CHECK 

*EC 

.  Ik 

.  Ik 

.  23«5. 

A/D  CONVERTER  STORED  ON  mac.  Tape 

AC 

,  I” 

.  IH 

.  274. 

CHECK  "E*EC’  TAPE 

MEDIT 

,  I" 

.  Ik 

.  216. 

PfMOVE  U^iKTen  DATA  P*0M  "EXFC"  TAPE 

must 

.  T* 

.  /K 

.  22«6. 

perform  engineering  UMTS  CONVERSION  AND  LIST 

reo*  "MFC"  TAPE 

nniiMD 

.  I" 

.  Ik 

.  21*. 

perform  ENGINEERING  UNITS  CDnvfRSIDn  and  LIST 

Fen*/  we*E.C"  TAPf 

PI 'IT 

• 

•  T  M 

LOAD  A  f.p  VEP1PV  PC 
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PREDICTIVE  SOFTWARE  COST  MOO  EL 


CONTINUATION  SHEET 


DATE:  28  Sept  1979 


■PRHN 

.  I" 

.  Is 

irrr. 

RECOVER  MRll  DATA  ThRUDGs  DC  STORE  O'.  TEMPORARY 

• 

• 

• 

DATA  FILE 

M 

t  TH 

•  Is 

mu. 

RECOVER  ANALOG  FM  DATA,  STORE  ON  TfsPORAPT  DaTa 

• 

t 

• 

FILE 

•c« 

,  IH 

.  Is 

219, 

LOAD  AND  VERIFY  7oo 1 S  FOP  PCM  DATA/STRIP  CHARTS 

■Cmmm 

.  I” 

.  is 

1406, 

recover  PC“  DATA,  STORE  ON  temporary  DATA  file 

;DF20K 

.  IH 

.  Is 

TS, 

STORF  REFERENCE  Data  FILE  On  DISK  to  FREF  tape 

• 

• 

• 

DRIVE 

ALS 

>  IS 

,  Is 

136. 

GENERATES  CALIBRATION  library  FOR  Fm  op  PCM  RUN 

:aIOk 

,  IS 

.  Is 

60, 

PRINT  AND  VERIFY  CALIBRATION  LIBRARY 

'PST  aT 

.  IS 

.  Is 

447. 

PERFORM  STATISTICAL  AND  TIME  ANALYSIS  OF 

• 

• 

• 

TEMPORARY  DATA  FILE (S) 

•PDL'mP 

.  Is 

256. 

LIST  SELECTED  PARAMETERS  FR0H  TEMPORARY  data 

• 

• 

• 

FILE ( S) 

ll  IMP 

.  Is 

.  Is 

238. 

LIST  SELECTED  PARAMETERS  FROM  TEMPORARY  DATA 

• 

• 

• 

FILE  CS J 

'03 

,  IS 

.  Is 

402, 

CHECK  FM  SYSTEM 

'OS 

.  Is 

.  Is 

165. 

CHECK  CALIBRATION  ID/TAPE  BREAK  SYSTEM 

'01 

.  Is 

.  Is 

457. 

CHECK  DC  LOAD 

’0? 

.  IS 

.  Is 

544, 

GROSS  CHECK  OF  MKH  SYSTEM 

iCALr. 

.  IS 

.  Is 

30. 

RECOVER  MK 1 1  DaTa  AND  STORE  ON  MAGNETIC  TAPE 

JCD'JMP 

■  Is 

.  Is 

128. 

RECOVfP  MKII  DaTa  and  STORE  ON  MAGNETIC  TAPE 

ICTES’ 

.  is 

•  Is 

30. 

CHECK  DC 

roo 

,  Is 

.  Is 

421  , 

CHECK  SIMULATOR  TO  COMPUTER  COMMUNICATIONS 

f07 

.  Is 

.  Is 

1463. 

CHECK  SIMULATOR  TO  COMPUTER  COMMUNICATIONS 

f09 

.  IS 

.  is 

1  453. 

CHECK  SIMULATOR  TO  COMPUTER  COMMUNICATIONS 

iPI«E 

.  IS 

.  Is 

932. 

FLAGS  time  OF  VOLTAGE  SPIKES 

rJRE 

.  is 

.  Is 

361, 

SEPARATE  I/O  commutated  VALUES  FPQm  UP  To 

• 

• 

• 
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jatt 

*  1 H 

.  Is 
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SEPARATES  I/O  COMMUTATED  VALUES 
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• 

• 

• 

• 
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PREDICTIVE  SOFTWARE  COST  MOOEL 


CONTINUATION  SHEET 


UATi:  28  < 


,  TERMINAL  CASSETTE 

SL0* 

•  I* 

,  IH 

.  SETS  TERMINAL  PA'ID  RATE  TO  2«0U 

SPACE 

.  TH 

,  IH  , 

,  GIVES  REMAINS  HUMBER  Of  BLOCKS  OH  A  DISK 

SPOOL 

•  IH 

.  IM  . 

.  COPIES  FILES  TO  THE  LIRE  PRINTER  »ITh  PagI 

t 

t  • 

,  AHD  TITLING 

TE 

•  I M 

.  IH  . 

.  TEXT  EOITOP 

WRITE 

•  IH 

,  IM  . 

.  COPIES  AN  ASCII  FILE  TO  A  HEWLETT-PACKARD 

•  IH 

.  IH 

,  CASSETTE 

PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  - 


FLIGHT  TEST  REQUIREMENTS _ DATE:  28  Sept  1979 

Typically  it  will  take  about  four  to  ten  (average  about  six)  sorties  to  get  the 
system  running  smoothly  before  testing  can  begin  in  earnest.  Flight  test 
statistics  are  as  follows: 

Block  Change  Nr.  Sorties  Nr.  Flight  Hours 

FB-15  23  67 

FB-16  19  60.5 

$10,000  per  sortie  is  used  by  SMALC  is  a  rough  cost  estimate  for  Flight  test¬ 
ing,  including  system  preparation  and  range  costs.  Calculations  based  on 
figures  from  AFR  173-10,  USAF  Cost  and  Planning  Factors,  Volume  I,  May  1977, 
yield  a  cost  per  flight  hour  of  $2,957. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  MAINTENANCE  HISTORY _ DATE:  28  Sept  1979 


DESCRIPTION 
SINCE  PMRT 

OF  NUMBERS  AND  TYPES  OF  MAINTENANCE 

ACTIONS  PERFORMED 

EACH  YEAR 

SOFTWARE  CHANGE  SUMMARY  FOR 

THE  FB-111A  OFP 

FB-12  FB-13  FB-14  FB-15  FB-16 

Release  Date  9-74  1-76  1-78  1-78  Sched.6-79 

Change  Requirement  Code 

Total 

A  - 

Add  Capability  3  1 

1  2 

8 

15 

C  - 

Correct  Deficiency  6  13 

4  7 

8 

38 

D  - 

Delete  Capability  2  6 

0  5 

3 

16 

E  - 

Enhancement  4  10 

8  5 

5 

32 

0  - 

Optimization  0  0 

1  0 

1 

2 

Total  15  30 

14  19 

25 

103 

T-  * 

CHANGES  SOLVED  IN 

FB-12 

Change 

Title 

Code 

B442 

Designate  switch 

A 

B443 

Improved  wind  vector  fix 

C 

B452 

Heading  fix  mode 

A 

B480 

Altitude  calibration  in  bomb  or  Alla 

modes 

C 

B464 

Delivery  mode  switch/bomb  incompatibility  indication 

C 

B508 

Zero  core  at  power-up 

C 

B509 

PCO  of  computer  error  traps 

E 

B427 

Converter  bite  failure  reporting 

C 

B449 

Entered  PSIMV  in  Alia  mode 

E 

B463 

Retention  of  MTH  corrections  during  Nav/Bomb  transition 

E 

B467 

Cursor  initialization  in  ground  align  mode 

C 

B468 

NDU  displays  in  bomb  mode 

A 

B469 

Retention  of  MTH  corrections  during  Bomb/Nav  transition 

E 

B12WSAV 

Capabilities  deleted 

A.  Visual  auto  PP  correction 

D 

B.  Visual  auto  fixpoint  ID 

D 

\ko 


PREDICTIVE  SOFTWARE  COST  MOOEL 

CONTINUATION  SHEET _ PATi:  2ft  s«>nr  1Q7Q 


Change 

CHANGES  SOLVED  IN  FB-13 

Title 

Code 

B526 

SRAM  Alternate  Launch  (SAL) 

A 

B522 

Present  position  update  reasonableness  test 

E 

B430 

Use  of  doppler  boresight  and  scale  factor 

C 

B407 

Doppler  memory 

E 

B494 

Transport  precession  correction  in  directional  gyro  mode 

C 

B485 

flight  alignment  (IFA)/initialization  with  INS  true  heading 

C 

B501 

Inflight  alignment  restart 

C 

B527 

Visual  indication  for  heading  fix  mode  entry  and  exit 

C 

B514 

"INS  mode"  error  light  timing 

C 

B513 

Delete  800  Ft.  check  for  high  altitude  calibration 

D 

B547 

Magnetic  variation  initialization/ground  alignment 

C 

B473 

Magnetic  variation  initialization/dead  reckoning  to  inertial  mode 

C 

B53Q 

Same  coordinates  fix 

B524 

Doppler  radar  system  bore  sight  and  scale  factor  storage  control 

E 

B528 

Whole  value  entry  of  Magvar  and  wind  velocity  in  DR  mode 

E 

E515 

System  altitude  lag  refinements 

E 

B478 

Ballistics  coefficients 

E 

B516 

B-43  weight  (SC-9  tail) 

E 

B474 

System  magnetic  variation  (MV)  in  inertial  mode  (I) 

E 

B529 

SRAM  integrated  system  checkout  (ISC)  fix 

E 

B531 

Reduced  time-to-go  (TTG)  window 

C 

B532 

SRAM  power  up  delay  fix 

C 

B533 

Astro  self  test  tolerances 

E 

B534 

Correct  heading  fix  wind  rotation 

C 

B535 

Radar  cursor  jump  GNC  halt  aila  or  radar  bomb 

C 

B13WSAV 

Capabilities  deleted 

A.  Right  hand  race  track 

D 

B.  Dive  weapon  release 

D 

C.  Ladd  weapon  release 

D 

D.  Guns  and  rockets 

D 

E.  Maneuvering  modes  and  vertical  range 

D 

l1*! 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  28  Sept  1979 


CHANGES  SOLVED  IN  FB-14  (RELEASED  WITH  FB-15) 

Title 

Selected  sequence  point  cursor  control 

System  command  code  table 

Inability  to  sequence  interrupt  in  offset 

Doppler  over  water 

Attack  steering  sensitivity 

Optional  corrections  to  INS  if  present  position  reasonableness 
test  failed 

Kalman  model  for  doppler-inertial  navigation 
No  automatic  SRAM  channel  changeover 
Hand  entry  of  manual  altitude 
Unfreeze  TAS  option 

Rescaling  of  TFR  inertial  flight  vector 
Inhibit  sequencing  during  visual  overfly 

New  weapons  and  new  ballistics  for  weapons  in  permanent  memory 
Move  DG  and  bores ight  commands  to  syscom  table 
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PREDICTIVE  SOFTWARE  C08T  MODEL 


CONTINUATION  SHEET 


DATE:  28  SeDt  1979 


CHANGES  SOLVED  IN  FB-15 


Change 


Title 


B15WSAV 


Mechanize  Kalman  filter  for  WDC 
Moving  target  designation 

Wind  errors  in  wind  vector/heading  fix  combination 

Converter  set  synchro  output  bite  deficiency 

Rate  group  overload  fault  trap 

Erroneous  heading  fix  enables 

Bomb  mode  computer  recycling 

Astro  capability  in  dead  reckoning  modes 

PCO  error  trap  enhancement 

Improve  SRAM  fault  reporting 

Minimum  vertical  range  to  target 

Altitude  drift  during  high  altitude  calibration 

Steering  in  visual  BOM  mode 

Display  range  in  manual  ballistics 

Capabilities  deleted 

A.  Horizontal  situation  display 

B.  Manual  update 

C.  Conventional  filter  cycle 

D.  Manual  navigation 

E.  RHAW  homing  mode 


PREDICTIVE  SOFTWARE  COST  MOO  EL 


CONTINUATION  SHEET _ _ _ DATE:  28  Sept  197 

CHANGES  SOLVED  IN  FB-16  (SCHEDULED  FOR  RELEASE  6/79) 


:  Change  Title  Code 

B612  Short  range  attack  missile  (SRAM)  airborne  mission  trainer  A 

(SAMIT) 

B589  Selectable  fixpoint  quality  A 

B600  Wind  vector  present  position  fix  combination  E 

B606  Special  "Enter  Visual  Fix"  (EVF)  A 

B608  Fixpoint  identification  (FXPT  ID)  0 

B609  Fixpoint  selected  sequence  point  pushbutton  A 

B613  Ground  navigate  mode  A 

B585  Backup  fault  reporting  E 

B549  Weapon  release  data  trap  A 

B596  Incorrect  ballistics  in  manual  altitude  C 

B602  Doppler  ground  speed/drift  correction  angle  filter  E 

B610  ECP  3268  R01  C 

B422  Fixpoint  identification  sequence  numbers  C 

B547  Computer  halt  with  invalid  switch  positions  C 

B587  Directional  gyrocompass  mode  problem  C 

B588  True  air  speed- inertial  inflight  alignment  problem  C 

B601  Manual  true  air  speed  E 

B611  Bomb  mode  wind  vector/heading  fix  abort  change  E 

B594  Short  range  attack  missile  (SRAM)  channel  switchover  logic  C 

B598  Correct  Akuron  equations  C 

B605  Astro  elevation  display  A 

B614  Whole  value  update  of  present  position  in  degraded  modes  A 

B16WSAV  Capabilities  deleted 

A.  Homer  set/Homer  track  fixtaking  modes  D 

B.  Blast  radius/yield  code  D 

C.  Course  line/course  select  steering  D 


PREDICTIVE  SOFTWARE  COST  MODEL 

SOFTWARE  PACKAGE  MAINTENANCE  COST  HISTORY _ DATE:  2fi  s» 

YEARLY  COST  OF  MAINTAINING  PACKAGE: 

Manhours  expended  in  support  of  the  FB-111A  are  as  follows: 


FY77 

FY  78 

FY79 

Direct  FB-111A  Support 

18041 

15069 

9809 

Support  Software1 

23790 

29776 

21094 

Manhours  by  block  change  are  shown  on  p.  b-80. 

Vendor  support  of  the  Harris,  Interdata  and  PDP  computers  costs  $308K/year  plus 
$126K/year  for  expendables  and  prototype  hardware  (split  about  50/50). 


1.  For  FB-111A,  F-111D  and  F-111F,  plus  other  projects. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  -  MAINTENANCE  COST  HISTORY 


DATE:  28  Sept 


CHANGE 

Block 

A 

C 

D 

E 

0 

FB-12 

(released 

9-74) 

3 

6 

2 

4 

0 

FB-13 

(released 

1-76) 

1 

13 

6 

10 

0 

FB-14 

(released 

1-78) 

1 

4 

0 

8 

1 

FB-15 

(released 

1-78) 

2 

7 

5 

5 

0 

FB-16 

(released 

6-79) 

8 

8 

3 

5 

1 

FB-17 

(scheduled  for 
release  late 
1980) 


Total  Manhour  (FY'77  -  FY”79) 


15 

n/a 

30 

n/a 

14 

329 

19 

18080 

25 

21519 

2867 

1979 
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PREDICTIVE  SOFTWARE  COST  MODEL 


HISTORICAL  DATA  SOURCES 

Data  Base  Name 
Location 
Contact  Person 
Phone  Number 
General  Contents 

Period  Covered 
Data  Quality 


_ D*TE:  28  Sec 

F/FB-lll  Operational  Flight  Program 
SM-ALC/MMECP,  McClellan  AFB,  California 
Alton  E.  Patterson 
(916)643-4762 

Manhours  by  Fiscal  Year  by  function/ 
proj  ect 

FY'77  through  FY'79 

Good  detail  on  expenditure  of  manhours, 
down  to  level  of  OFP  block  change 


PREDICTIVE  SOFTWARE  COST  MODEL 


RECOMMENDATIONS  RE  SOFTWARE  SUPPORT  COST  PREDICTING 


RESPONDENT:  Bassett 


DATE:  28  Sept  1979 


If  you  were  responsible  for  predicting,  accumulating  and  accounting  for  software 
support  costs,  how  would  you  do  it? 

1.  AF  Flight  simulator  concept  (requirements  different  than  A/C)  -  Need  to  be 
able  to  update  flight  simulator  by  just  changing  OFP  software. 

2.  a.  Demand  spare  memory 

b.  Language  -  Function  of  application 

Need  to  study  tradeoff  between  ease  of  development /maintenance  vs. 
operational  requirements  (efficient  code) 

Can  HOL  support  those  requirements? 

Support  -  peculiar  language  -  need  to  buy  original  contractor 

c.  Mission  requirements 

TAC  has  more  precise  testing  requirements  than  SAC. 

(Weapon  delivery  precision)  [smart  weapons]' 

d.  SPO  is  not  motivated  toward  economical  support 

AFLC  needs  veto  power  over  design  decisions 

Similarities  among  aircraft  avionics  are  greater  than  differences. 

e.  Analysis  and  design  and  testing  overwhelms  compilation /assembly. 

f.  Support  personnel  cost  more  than  development  personnel 

(Need  system  knowledge.  Implies  experience.) 

Autonetics  -  $65K/man  year 
GD  -  $35K/man  year 
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PREDICTIVE  SOFTWARE  COST  MODEL 
FIELD  EVALUATION  REPORT 

GENERAL  SOFTWARE  PACKAGE  DESCRIPTION _ DATE:  28  Sent  1979 


ALC:  SM 

WEAPON  SYSTEM:  F-111F 

SOFTWARE  PACKAGE:  General  Navigation  Computer/Weapons  Delivery  Computer 

PERSONNEL  CONTACTED: 


A1  Patterson,  MMECP 
Lynn  Bassett,  MMECP 


SOFTWARE  PACKAGE  CHARACTERISTICS:  (two  packages  -  see  page  C-2)  . 

SIZE:  16K  each  for  General  Navigation  Computer  (GNC)  and  Weapons  Delivery 
Computer  (WDC) . 

LANGUAGE:  Assembly 

application:  Navigation,  Weapons  Delivery 
COMPLEXITY:  High 
YEAR  DEVELOPED:  1968 
DEVELOPER:  Autonetics 

comments  Minimal  attention  given  to  software  reliability  and  maintainability. 
See  rating  of  quality  attributes  on  page  c-3. 

HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS:  (two  computers) 

MANUFACTURER:  IBM 

MODEL  NUMBER/DESIGNATOR:  CP2 
WORD  SIZE:  16-bit 
MEMORY  SIZE:  16K  each 

memory  fill:  200  empty  words  each  (98.8  percent) 

WEAPON  SYSTEM  USE: 

NUMBER  OF  USERS:  94 

LOCATIONS  OF  USERS:  Lakenheath,  England 

FREQUENCY  OF  USE:  Daily 

INTERVIEWERIS):  R,  B.  Waina,  A.  P.  Bangs 
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Rate  the  Package  on  the  following  Quality 

attributes : 

Accessibility:  0 

Instrumentation:  4 

Accountability:  N/R 

Interoperability:  0 

Access  Audit:  N/R 

Integrity:  10 

Access  Control:  N/R 

Legibility:  5 

Accuracy:  9 

Maintainability:  8 

Augmentability :  6 

Modifiability:  8 

Clarity:  4 

Modularity:  4 

Communi cativeness:  8 

Operability:  N/A 

Communications,  Commonality:  N/A 

Performance:  10 

Completeness:  9 

Portability:  0 

Conciseness:  9 

Reliability:  9 

Cons istency : 

Robustness:  8 

Internal  Consistency:  7 

External  Consistency:  8 

Correctness:  10 

Data  Commonality:  N/A 

Efficiency:  10 

Execution  Efficiency:  10 

Reusability:  0 

Selfcontainedness:  10 

Selfdescriptiveness:  5 

Simplicity:  3 

Structuredness:  7 

Storage  Efficiency:  10 

Testability:  8 

Error  Tolerance:  9 

Traceability:  8 

Expandability:  6 

Training:  N/A 

Generality:  0 

Understandability:  4 

Hunan  Engineering:  9 

Independence:  0 

Device:  0 

Software  System:  0 

Usability  (as-is  utility):  9 
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ALC:  SM 


KEY  PERSONNEL/OGRANIZATION: 


DATE:  28  Sept  1979 


OFFICE  SYMBOL:  MMECP 


MMEC 

Hr.  Robert  Green 


MMECP 

Mr.  A1  Patterson 
F/FB-111 


MMECM 

Mr.  Frank  Davis 
Software 
Management 


MMECS 

Major  Hank  Garretson 
Administration 


MMECF 

Mr.  Bob  La  Vergne 
Ground  Communica¬ 
tions,  Electronics, 
and  Meterological 


TOTAL  ASSIGNED  PERSONNEL  (NUMBER  &  TYPE):  (MMECP) 

4  Air  Force  (2-3  years  experience) 

19  Civil  Service  (3-5  years  experience) 

30  General  Dynamics  (2-3  years  experience) 

31  Autonetics  (8-10  years  experience) 


TOTAL  PACKAGES  MAINTAINED  (NUMBER  &  TYPE): 


7  -  one  OFP  for  each  of  the  two  computers  (GNC  and  WDC)  for  each  of  the  three 
aircraft,  (F-111D,  F-111F,  FB-111A),  plus  one  OFP  for  the  NCU  computer  program 
for  all  three  aircraft.  Additionally,  much  simulation  and  support  software  is 
maintained,  and  numerous  special  projects  are  carried  out. 
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DATE: 28  Seot  197 


DESCRIPTION  OF  WORK  PACKAGE  DISTRIBUTION,  INCLUDING  RESPONSIBILITIES  AND  DEGREE  OF 
SPECIALIZATION  OF  AF/CS/CONTR  PERSONNEL  (MMECP) 

NUMBER  OP  PERSONNEL 

FUNCTION  AF  CS  CONTR 

Management/Secretary  4  3 

FB-111A  S/W  Engineering  1  5 

F-111D  S/W  Engineering  1  5 

F-lllF/Pavetack  S/W  1  5 

Engineering 

Mission  Programs  1  3 

F-lll  A/E  Acquisition  2  1 

Support 

F-lll  AISF  Enhancements  15 

and  S/W  Support 

F-lll  OFP  Mk  II  V  &  V  3  3 

Flight  Test  Support  5 

S/W  Configuration  4 

Management 


Special  Projects 
Major  AISF  Upgrades 


[5-10  off -premise] 
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DATE:  28  Sept  1979 


Manhours  for  FY'77  through  FY'79  are  distributed  as  follows: 


Function 

FY'77 

FY'78 

FY'79 

FB-111A 

18,041 

15,069 

9,809 

F-111F 

16,926 

8,877 

20,243 

F-111D 

13,880 

19,376 

14,373 

Other  F-lll 

6,391 

3,288 

6,467 

Support  Software 

23,790 

29,776 

21,094 

Special  Projects 

28,982 

35,224 

33,548 

Leave/Hollday 

19,904 

23,580 

24,597 

Total 

127,914 

135,190 

129,131 
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MAINTENANCE  AGENCY  -  COST  ACCOUNTING  SYSTEM _ DATE:  28  Sept  1979 


SMALC  uses  a  manhour  accounting  system  which  logs  manhours  by  project.  For  each 
specific  aircraft  type  block  change,  manhours  are  accounted  for  by  five  functions: 
management,  definition,  development,  documentation  and  test.  There  is  also  a 
category  for  OFP  Group  Management.  Beyond  that,  individual  functions  (e.g., 
configuration  management)  and  projects  are  tracked. 
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DATE:  28  Sept  1979 


SUPPORT  PHILOSOPHY: 


AFLC  needs  to  utilize  its  resources  effectively  and  efficiently  in  maintaining  and 
updating  OFP's.  A  system  entitled  F-lll  OFP  Change  and  Control  has  been  implements 
in  support  of  the  F-lll  aircraft.  OFP's  provide  aircraft  systems  with  tremendous 
flexibility,  provided  changes  can  be  made  to  them  in  a  timely  manner.  New  aircraft 
capabilities,  enhancements  and  improvements  can  be  achieved  through  changes  to  GFP’ 
For  example,  capabilities  and  improvements  added  to  the  F-lll  through  OFP  changes 
include  SRAM  alternate  launch,  moving  target  detect,  expanded  offset  aimpoints, 
improved  beacon  bombing,  enhanced  fixtaking,  expanded  steerpoints,  updated 
ballistics,  and  added  avionics  diagnostics.  In  addition,  many  modes  have  been 
improved,  changed  or  deleted;  navigation  and  bombing  performance  has  been  improved 
and  numerous  latent  deficiencies  corrected.  This  has  been  accomplished  through 
some  177  OFP  changes  over  a  3-year  period. 

The  concept  developed  which  permits  OFP  change  activity  of  this  order  is  the 
OFP  clock  Change.  A  block  change  is  a  collection  of  OFP  changes  (i,e.,  so  f  r*-;r .- 
cnanges  only — no  hardware  impacts)  which  are  concurrently  processed  and  integrated 
(cont.  on  p.  C-°.) _ _ _ 

CHANGE  CONTROL  METHODS: 

FORMAL  OR  INFORMAL:  Very  formal 


CHANGE  REVIEW  PROCESS:  See  pages  C-10  through  C-17 


CONFIGURATION  IDENTIFICATION  METHODS:  See  page  C-ll  ff 


CONFIGURATION  CHANGE  CONTROL  METHODS:  See  page  C-15  ft 


CONFIGURATION  STATUS  ACCOUNTING  METHODS:  Within  the  change  process  a  base. me 
tape  is  generated.  Individual  changes  are  then  keyed  in  ay  number.  Sce 
description  of  the  "dot-files ,”  pages  i  - 21/2.3. 

SOFTWARE  LIBRARY  CONTROL  PROCEDURES: 
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into  the  baseline  program  over  some  period  of  time.  Since  changes  to  OFP's  are 
viewed  as  a  continuing  task  over  the  life  cycle  of  the  aircraft  system,  the  block 
change  becomes  a  cyclic  process.  Efficiency  is  derived  through  a  level  of  effort 
staffing  and  collective  OFP  change  processing.  Responsiveness  is  derived  by 
keeping  the  cycle  time  to  limits  acceptable  to  the  user.  Obvious  tradeoffs  are 
level  of  effort  staffing,  number  of  changes  in  a  blocK.  change  and  cycle  time. 

For  long-term  efficiency  the  level  of  effort  and  cycle  time  are  fixed  and  the 
parameter  that  varies  from  block  change  to  block  change  is  the  number  of  OFP 
changes.  This,  of  course,  varies  as  a  function  of  the  priorities  of  change 
candidates  and  the  magnitude  and  complexity  of  each.  Flexibility  is  achieved 
in  several  ways.  First,  emergency  changes  can  be  expedited  by  processing  on  an 
individual  basis.  Depending  on  change  magnitude,  complexity  and  risk,  it  is 
possible  to  process  these  changes  in  a  matter  of  weeks.  Further,  depending  on 
priority  and  complexity,  changes  can  be  added  or  deleted  from  the  block  change 
until  late  in  the  change  cycle,  i.e.,  until  configuration  freeze.  Finally, 
configuration  control  procedures  have  been  set  up  in  accordance  with  AER  800-14 
to  process  Computer  Program  Change  Proposals  (CPCP's)  Outside  of  the  hardware 
configuration  change  process.  A  CPCP  is  the  vehicle  used  for  identification  and 
approval  of  the  OFP  Block  Change  and  attendant  weapon  system  impacts.  These 
procedures,  in  addition  to  adding  flexibility,  also  greatly  improve  the  responsive¬ 
ness  of  the  change  system.  Of  course,  with  flexibility  of  this  nature,  strict 
control  and  complete  documentation  is  essential  for  configuration  management. 
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OFP  BLOCK  CHANGE  CYCLE: 

FlgureC-3depicts  the  development  cycle  used  for  F-lll  OFP  Block  Changes  and  Is 
similiar  to  the  standard  software  development  cycle.  It  includes  the  major  phases 
of  analysis,  feasibility,  design,  development,  test,  documentation  and  delivery. 

As  shown  in  Figure  C-3  each  phase  starts  and  finishes  with  well  defined  milestones. 
The  cycle  is  periodic  with  a  3-month  overlap  and  produces  updated  OFP's  for  the 
user  on  an  annual  basis.  Tradeoffs  which  dictated  cycle  time  were  F-lll  change 
activity,  required  user  response,  and  available  support  resources.  However, 
other  practical  considerations  which  limit  the  minimum  cycle  time  are  mission 
simulator  updates,  availability  of  test  aircraft,  crew  training,  and  documentation 
update. 

Referring  to  Figure  C-3  the  change  cycle  starts  with  a  requirements  review.  This 
is  a  user,  system  manager,  engineering  review  where  problems  and  change  require¬ 
ments  which  have  accumulated  over  the  past  year  are  reviewed  and  prioritized. 

The  Operational  Software  Requirements  Document  (OSRD)  is  updated  and  the 
feasibility  study  defined. 


PROBLEM/RQMT5  /  < 
INVESTIGATION  /  .*• 

/  ^>  .<5 


A  /A 


/ j?  X  £/ 


IDDOODODaDQIIDDDDIfl 


•  RQMTS  REVIEW 


■  DEFINITION - ' 

•  CPCP  SUBMITTAL - 

•  CPCP  APPROVAL - 

•  PROJECT  TEST  PLAN - 

•  INTEGRATE  CHANGES'! 

•  f LIGHT  TEST  RQMTSJ 

•  TEST  PLANNING  MEETING] _ 

•  USER  LAB  DEM.O  _| 

•  INTEGRATION  TEST  &  EVALUATION - 

•  fORMAL  LAB  TEST  4  EVALUATION - 

•  ENGR  FLIGHT  TEST - 

•  OT&E  FLIGHT  TEST - 

•  USER  MEETING  4  CONFIGURATION  FREEZE- 

•TECH  DATA  V1V/FREEZE - 

•  FLIGHT  TES'  COMPLETE - 

•  PRODUCTION  PROG  VERIFICATION - 

•  FINAL  TEST  REPORT - 

•  TECH  DATA  MASTERS - 

•  RELEASE  AND  FINAL  REPORT - 


FlgureC-3.  Operational  Flight  Program  Change  Cycle 
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The  Feasibility  Study  Phase  is  conducted  by  engineering  in  accordance  with  user 
priority.  It  primarily  consists  of:  determining  the  update  task  for  each  change; 
scoping  the  resource  requirements;  investigating  change  impacts  on  other  parts  of 
the  weapon  system  and  support  equipment;  looking  at  computer  memory  and  timing 
impacts;  investigating  integration  problems;  and  determining  if  each  change 
requirement  is  technically  feasible  and  will  actually  provide  the  user  with 
what  is  expected.  The  results  of  the  feasibility  study  are  then  presented  at  an 
OFP  Block  Change  Definition  meeting  attended  by  the  user,  the  system  manager  and 
engineering.  Based  on  the  results  of  the  feasibility  study,  an  OFP  Block  Change 
Definition  is  established  and  agreed  to.  Constraints  adhered  to  are:  the  block 
change  contains  only  change  candidates  which  do  not  impact  hardware;  the  changes 
can  be  worked  within  existing  resources;  and  the  cycle  time  is  maintained.  Changes 
which  do  not  meet  these  constraints  are  referred  to  the  system  manager  for 
processing  in  accordance  with  hardware  procedures.  The  main  output  of  the  feasi¬ 
bility  study  is  the  OFP  Block  Change  Requirements  Document. 

The  Preliminary  Design  Phase  consists  of:  translating  requirements  into  engineer¬ 
ing  terms;  updating  flow  charts  and  logic  layouts,  defining  mechanization,  inter¬ 
face,  scaling,  and  timing  requirements;  developing  change  narratives;  determining 
the  scope  of  impact  to  documentation,  technical  orders,  mission  simulator  and  other 
weapon  system  software;  and  preparing  and  submitting  the  Computer  Program  Change 
Proposal  (CPCP) . 

The  Initial  Development  Phase  consists  of:  establishing  the  development  baseline 
block  change  programs;  firming  up  mechanization;  programming  and  testing  prelim¬ 
inary  code;  and  establishing  documentation  files. 

The  Development  Phase  begins  with  the  approval  of  the  CPCP  by  both  the  user  and 
system  manager.  The  development  phase  consist  of:  finalizing  and  testing  program 
code  for  each  OFP  change;  developing  engineering  tapes,  addendums,  and  documenta¬ 
tion;  developing  change  descriptions;  developing  the  project  test  plan;  developing 
flight  test,  data  reduction  and  instrumentation  test  requirements;  preparing  test 
procedures;  and  providing  preliminary  data  for  mission  simulator  updates. 

The  Integration  and  Implementation  Phase  begins  with  the  laboratory  integration  of 
all  OFP  Block  Change  requirements.  A  user/engineering  meeting  is  convened  to  discus: 
engineering  and  user  flight  test  policy  and  to  conduct  a  laboratory  demonstration 
of  each  OFP  change.  Final  reassembly  of  all  approved  OFP  changes  with  the  develop¬ 
ment  baseline  program  is  accomplished  and  the  master  engineering  OFP  tape  produced. 
Formal  verification  testing  and  evaluation  by  the  development  engineering  group  is 
completed.  Engineering  source  data  for  technical  orders  and  engineering  documenta¬ 
tion  is  developed.  Formal  test  and  evaluation  procedures  are  finalized.  The  missior 
and  weapon  control  programs  are  produced.  Laboratory  test  and  flight  test  aircraft 
configurations  are  established  to  include  aircraft  computer  data  pumps  and  data 
reduction  software.  These  steps  are  in  preparation  for  formal  test  and  evaluation. 

The  Formal  Test  and  Evaluation  Phase  starts  with  the  turnover  of  the  master  engineer¬ 
ing  OFP  tape  to  a  separate  engineering  group  for  test  and  evaluation.  Formal 
testing  consists  of  a  three  phase  laboratory  test,  instrumented  engineering  flight 
test,  and  user  Operational  Test  and  Evaluation  (OT&E) .  Phase  I  of  laboratory 
testing  is  a  dynamic  functional  test  of  all  OFP  modes.  When  completed,  the  master 
engineering  OFP  tape  is  cleared  for  engineering  flight  test.  Initial  engineering 
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flight  test  looks  at  overall  air  suitability  and  clears  the  master  engineering 
OFP  tape  for  user  OT&E.  Once  cleared,  OT&E  and  final  engineering  flight  test  are 
conducted  concurrently.  Phase  II  and  III  of  the  formal  laboratory  test  are  also 
run  concurrently .  Phase  II  is  a  quantitative  test  of  performance,  a  look  at 
performance  envelopes  and  an  inspection  of  code  and  baseline  documents.  Phase  III 
is  the  retesting  of  modifications  resulting  from  problems  discovered  during  test. 
Part  way  through  formal  testing  a  meeting  between  the  user  and  engineering  is 
convened  to  review  test  results  and  to  establish  an  OFP  Block  Change  configuration 
freeze.  Mandatory  corrections  to  program  discrepancies  are  defined,  implemented 
and  retested;  trivial  anomalies  are  accepted;  and  in  the  event  a  change  cannot 
be  accomplished,  its  coding  is  removed.  Also,  during  this  phase  technical  order 
source  data  is  verified  and  validated  by  the  user,  engineering  and  the  system 
manager.  Source  inputs  for  the  mission  simulator  updates  are  finalized  and 
delivered.  At  the  completion  of  the  formal  test  phase,  the  master  OFP  engineering 
addendum  tape,  incorporating  all  corrections  found  during  test,  is  merged  with  the 
master  engineering  OFP  tape  to  produce  the  engineering  OFP  release  tape  and  the 
final  OFP  Block  Change  documentation. 

During  the  Documentation  Phase  the  engineering  OFP  release  tape  it  converted  into 
a  production  version  and  tested.  All  engineering  documentation  is  finalized;  the 
technical  order  masters  are  prepared  and  made  ready  for  reproduction.  The 
evaluation  of  test  results  is  completed  and  the  final  test  report  is  issued. 

During  the  Publication  and  Preparation  for  Release  Phas  the  production  OFP  tapes 
are  duplicated;  engineering  documentation  and  technical  orders  are  published;  the 
final  OFP  Block  Change  Report  is  issued;  and  the  new  OFPs  and  associated  technical 
orders  are  concurrently  released  to  the  user  under  a  TCTO. 

OFP  BLOCK  CHANGE  PROCESS  A.<D  RESOURCE  UTILIZATION: 

Figure  C-4depicts  the  F— 111  OFP  Block  Change  process.  It  illustrates  several 
significant  points:  process  flow;  resource  utilization;  and  major  input/output 
products.  The  OFP  Block  Change  process  from  start  to  finish  is  highly  technical, 
and  primarily  involves  engineering  and  engineering  resources.  However,  system 
management,  technical  publications  and  user  participation  are  essential.  The 
system  manager  has  complete  responsibility  for  the  control,  coordination  and 
integration  of  OFP  changes  into  the  overall  integrated  logistics  management  support 
system  and  participates  to  that  extent.  The  user  is  intimately  involved  during 
feasibility  and  change  definition  to  establish  requirements  and  priorities,  and  to 
assure  that  requirements  are  properly  interpreted.  Further,  the  user  actively 
participates  during  the  integration  and  test  phases  so  that  performance  can  be 
verified  and  acceptance  granted  prior  to  configuration  freeze  and  OFP  release. 

The  user's  primary  participation  during  these  phases  is  in  the  laboratory  veri¬ 
fication.  During  the  documentation,  publication  and  preparation  for  release 
phases,  the  system  manager  and  technical  publications  are  extensively  involved 
in  the  preparation  and  publication  of  technical  orders,  the  duplication  of  OFP 
tapes  and  the  preparation  of  the  TCTO  for  release.  Engineering  is  responsible 
for  the  technical  management,  planning  and  direction  of  the  complete  OFP  change 
program  and  is  also  responsible  for  the  development  and  implementation  of  all  OFP 
changes.  Therefore,  engineering  is  actively  involved  in  all  phases  both  from  the 
program  management  and  technical  detail  aspects. 

As  noted  inFigure  C— AChe  engineering  resource  utilized  throughout  the  OFP  change 
process  is  the  Avionics  Integration  Support  Facility  (AISF) .  Figure  C-5 
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the  F— 111  AISF  which  consists  of  an  avionics  integration  area,  subsystem  test  area, 
OFP  dynamic  simulation  area,  computer  support  area  and  instrumented  flight  test 
aircraft.  The  integration,  simulation  and  computer  support  areas  are  used 
extensively  throughout  the  change  process  while  the  flight  test  capability  is 
extensively  used  during  the  test  and  evaluation  phase. 

The  integration  area,  which  contains  avionics  integraton  test  equipment  (ITE) , 
is  used  to  integrate  the  OFPs  with  the  avionics  system.  It  further  is  used  to 
recreate  flight  problems;  check  hardware /sof tware  interfaces;  evaluate  timing, 
stabilization  and  synchronization;  and  to  conduct  final  OFP/avionics  system 
compatibility  tests.  On-line  OFP  change  capability  is  available  in  this  area 
which  enables  efficient  and  expedient  implementation  of  trial  solutions. 
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FigureC-4,  OFP  Change  Process 
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The  F-lll  OFP  dynamic  simulation  area  provides  a  unique  capability  to 
quantitatively  analyze,  develop,  test  and  evaluate  OFP's  and  OFP  changes  under 
realistic  and  repeatable  conditions.  The  systems  are  hybrid  simulators  which 
retain  the  avionics  computers  with  their  resident  OFP's  and  simulate  the  world 
as  seen  by  these  computers  in  actual  flight.  Complete  visibility  is  gained 
into  the  innermost  parts  of  the  OFP's  through  data  monitoring  and  acquisition 
systems  which  provide  for  fqll  real-time  traces  of  OFP  execution.  Each  simu¬ 
lation  system  is  made  up  of  three  Harris  Corporation  6024/VM  mini-computer 
systems,  an  aircraft  cockpit  mock-up,  special  interface  devices  and  a 
simulation  software  package. 

The  computer  support  area  satisfies  all  computer  support  requirements  associated 
with  maintaining  and  updating  OFP's.  These  requirements  include  reassembly;  data 
reduction  and  analysis;  documentation  generation,  maintenance  and  storage; 
maintenance  of  support  software;  specialized  programs  and  programming;  and  auto¬ 
mated  configuration  control.  The  reassembly  and  automated  documentation  generation 
process  is  shown  in  FigureC-6.  The  computer  support  system  includes  two  Interdata 
8/32  mini-computer  systems,  a  PDP  11/40  mini-computer  system  and  a  remote  terminal 
to  an  IBM  360/65  complex. 


The  flight  test  capability  includes  El  coded  F-lll  aircraft  equipped  with  special 
instrumentation  packages  designed  specifically  for  monitoring  and  recording  OFP 
flight  performance.  Flights  are  conducted  to  test  overall  OFP  performance  and  air 
suitability;  analyze  change  and  problem  areas;  test  specific  modes  and  functions; 
and  to  obtain  engineering  data  to  define  and  verify  system  performance. 


|  HARDWARE  ANALYSIS 

•  Rivet  Gyro 

•  Test  Void  Reports 

•  Reliability 

•  Serviceability 

•  Environment* 


•ECPs 

•  Reliability  Modes 

•  New  Equipment 

•  Special  Projects 


RECOMMENDED  SYSTEM' 

i  f— 

OFF-LINE  COMPUTER  SUPPORT  AREA 

OTP  CHANCES  and/or 
ENG'G  RELEASE 

Mb  interdata  computing  system  I 

_ kl 

•  Addendum  Changes  Analysis  j 

y|  •  Confiqu ration  •  Off-Line  Programming  | 

Figure  C-5.  F-lll  Avionics  Integration  Support  Facility 
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FigureC-6.  OFP  Tape  and  Automated  Documentation  Generation 


The  AISF  technical  staff  consists  of  engineers,  programmers  and  technicians.  They 
encompass  a  spectrum  of  expertise  on  the  aircraft  system,  avionics,  computers, 
operational  software,  support  software,  bomb  navigation,  scientific  programming, 
instrumentation,  data  reduction,  systems  analysis,  configuration  management,  and 
equipment  and  software  maintenance. 

OFP  TAPE  AND  AUTOMATED  DOCUMENTATION  GENERATION: 


The  key  to  efficiently  making  OFP  changes  =tnd  controlling  configuration  lies  in 
an  automated  process  for  generating  OFP's  "md  all  associated  documentation.  Fig¬ 
ure  C-6.  illustrates  the  F-lll  OFP  Tape  and  Automated  Documentation  Generation 
System  which  ultimately  will  satisfy  this  goal.  To  date  the  process  performs 
the  reassembly,  documentation/  addendum  generation,  merge,  and  production  program 
conversions.  The  output  products  are  engineering  and  production  tapes,  program 
listings,  computer  files,  and  documentation. 

The  process  starts  with  the  reassembly  of  the  last  released  OFP  to  incorporate  the 
Master  Addendum  changes  along  with  subsequent  changes  to  optimize  program  coding 
for  memory  and  timing  benefits.  The  output  consists  of  the  development  baseline 
OFP  Inputs  to  the  Documentation  Program  during  development  and  integration 
include  engineering  development  data,  reassembly  code  and  the  specific  machine 
code  for  the  preparation  of  engineering  addendum  tapes.  The  documentation  and 
files  generated  from  the  Documentation  Program  include:  OFP  change  descriptions 
and  requirements,  change  objectives,  status,  mechanization,  assembly  code, 
machine  code  (for  key-ins  and  addendums);  flight  test,  instrumentation  and  data 
reduction  requirements;  test  procedures,  technical  order  impacts  and  historical 
data.  This  information  is  continuously  updated  during  the  OFP  Block  Change  cycle. 
Prior  to  formal  test  and  evaluation  the  final  development  addendum  is  reassembled 
with  the  development  baseline  to  produce  the  master  reassembled  engineering  base¬ 
line.  The  final  OFP  Block  Change  configuration  or  engineering  release  is  defined 
hy  the  reassembled  engineering  baseline  and  the  Master  Addendum.  Formal  testing 
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is  accumplished  only  with  the  computers  loaded  with  the  baseline  OFP  and  an 
approved  or  Master  Addendum  thereby  assuring  a  completely  documented  and  controlled 
configuration.  Current  plans  are  to  enhance  the  system  such  that  all  configuration 
control  documentation  listed  in  Figure  C-7  can  be  produced  using  this  system. 

OFP  CONFIGURATION  CONTROL  DOCUMENTS : 


The  OFP  Change  and  Control  System  provides  for  extreme  flexibility  and  therefore, 
strict  control  is  essential  if  OFP  configuration  is  to  be  maintained.  The  manage¬ 
ment  control  aspects  associated  with  OFP  changes,  and  the  change  process,  have 
been  described;  however,  essential  to  configuration  control  and  management  is  good 
documentation.  Since  software  is  intangible  (can't  see  or  touch  it),  the  documen¬ 
tation  must  be  very  thorough  in  describing  its  functional  and  performance  charac¬ 
teristics.  Equally  as  important  is  the  requirement  to  have  total  visibility  as 
to  how  these  characteristics  were  derived.  Without  documentation  that  does  these 
things,  the  on-going  change  process  would  eventually  collapse.  Figure  C-7  illus¬ 
trates  what  is  considered  a  complete  set  of  OFP  configuration  control  documents 
and  where  in  the  F-lll  OFP  change  cycle  these  documents  are  completed  and 
available.  The  list  is  confined  to  the  end  item  OFP  and  is  not  intended  to 
include  documentation  on  supporting  resources,  support  software  or  other  portions 
of  the  weapon  system  impacted  by  the  OFP  changes.  A  similar  set  of  documents  is 
obviously  required  for  these  areas.  An  exception  to  this  is  in  the  formal  test 
and  evaluation  process.  As  noted  in  Figure  7,  documents  defining  the  test  config¬ 
uration  of  the  laboratory,  test  aircraft,  and  mission  and  weapon  control  programs 
are  required.  If  and  when  other  test  resources  are  used  in  formal  testing,  their 
configuration  should  also  be  documented  and  become  a  part  of  the  OFP  configuration 
control  documents.  As  shown  in  Figure  7,  the  physical  documentation  includes 
both  automated  and  manually  prepared  documents  as  well  as  computer  stored  programs.! 


Current  change  requirements  and  problems  are  documented  in  the  Operational  Software1 
Requirements  Document  (OSRD) .  A  historical  list  of  all  requirements  and  problems, 
including  those  listed  in  the  OSRD,  is  maintained  in  the  Master  Software  Require¬ 
ments  Document  (MSRD) .  All  OFP  source  programs  and  programs  generated  after  the 
final  OFP  Block  Change  assembly  are  stored  on  magnetic  tape  and  hard  copy  listings 
are  maintained  on  microfilm  or  microfiche.  The  OFP  Block  Change  Requirements 
Document  defines  the  initial  block  change  definition  while  the  final  release  con¬ 
figuration  is  documented  using  the  previously  described  Documentation  Program. 

These  documents  become  a  part  of  the  OFP  Block  Change  Version  Description  Document 
(VDD).  The  Computer  Program  Change  Proposal  becomes  the  system  manager's  official 
configuration  control  document  and  is  updated  as  required  to  reflect  the  final 
released  OFP  configuration.  All  formal  test  requirements,  plans,  procedures,  and 
reports  become  a  part  of  the  VDD  and  are  a  record  of  actual  OFP  performance.  The 
OFP  Block  Change  Report  is  a  summary  of  total  block  change  activity  and  results. 

The  System  Program  Description  Document  (SPDD)  is  the  actual  OFP  specification 
and  is  updated  with  each  block  change.  It  describes  each  of  the  OFP  subroutines 
in  detail  and  includes:  narrative  descriptions,  inputs/outputs,  interfaces, 
logic,  timing,  equations,  and  flow  charts.  The  VDD  is  the  historical  record  of 
the  OFP  Block  Change  and  includes  all  other  block  change  documents.  In  summary, 
the  OFP  source  data,  SPDD  and  program  listings  actually  define  the  newly  released 
OFP  and  the  VDD  defines  the  OFP  Block  Change  to  it.  Technical  orders  generally 
aren't  considered  configuration  control  documents  but  are  shown  because  of  their 
importance  to  the  user  and  because  of  the  detail  they  offer  in  describing  the 
OFP's  and  their  relationship  to  the  aircraft  system  operation.  With  the  excep¬ 
tion  of  the  technical  orders,  all  documentation  is  stored  and  maintained  by 
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STRUCTURED  DESIGN?  -  DESCRIBE 

Minimal 

STRUCTURED  PROGRAMMING?  -  DESCRIBE 
Minimal 

CODING  GUIDELINES:  Experience  -  A  small  group  of  mechanization  engineers  is  used 
on  each  aircraft. 


CHANGE  ENTRY  METHODS:  CRT  terminal.  Interdata  is  used  for  an  on-line  record. 


SCHEDULE:  Formal  published  milestones,  formal  block  change  schedule. 


REPORTING:  Informal  in— house  reporting.  Formal  reports  to  users  are  via 

scheduled  meetings  (Ref.  Figure  3,  p.  C-10) . 


COMMENTS: 
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DOCUMENTATION: 


REQUIREMENTS:  Current  requirements  are  defined  in  meeting  minutes  and  in 
change  summaries  developed  by  engineers.  See  Computer 
Program  Change  Request  on  p.  C-20. 


DESIGN:  The  "dot"  files  are  used  for  design  documentation.  They  are 

described  on  pp.  C-21  and  C-22. 


USER:  User  documentation  is  provided  through  formal  changes  to  the 

system  tech  orders. 


See  Documentation  Guide,  pp.  C-23  through  C-42. 


PROGRAM  PROBLEM  REPORTING  SYSTEM: 

Users  generate  Computer  Program  Change  Requests.  These  are  formally  logged 
by  MMECP,  then  analyzed/prioritized  at  the  Requirements  Review  Meeting 
with  users. 


COMMENTS: 
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COMPUTER  PROGRAM  CHANGE  REQUEST 

Entered  by  SM/ALC 
I.D.  Number 


■ 

TITLE:  Enter  descriptive  title  2.  DATE: 

Enter  prepared  date 

3.  COMPUTER  PROGRAM  IDENTIFICATION: 

Enter  identification  of  program  affected 

4.  DESCRIPTION /PRESENT  OPERATION: 

Describe  in  detail  the  characteristics  of  computer  operation  or  use  as 
presently  mechanized,  including  aircrew  actions,  observed  reactions  of 
various  cockpit  displays  correlated  with  inputs  to  the  system  (including 
aircraft  maneuvering  or  switch  changes),  any  test  data  available,  and  any 
other  information  which  might  assist  in  identifying  the  cause  or  which 
might  aid  in  implementing  the  correction  or  change. 


5.  DESIRED  OPERATION: 

Describe  the  characteristics  of  computer  operation  or  use  desired  as  a 
result  of  this  change,  using  the  same  guidelines  as  under  "Present 
Operation. " 


6.  REASON  FOR  CHANGE: 

Present  the  rationale  behind  the  need  for  this  change,  emphasizing  the 
relative  importance  of  the  current  problem  and  the  desired  result. 


7.  CHANGE  HISTORY /RELATED  CHANGES: 

Information  to  be  supplied  by  Sacramento  ALC 


8.  REQUESTED  BY: 

Person  to  be  contacted  for 
further  information. 


9.  REQUESTING  AGENCY:  COORDINATION 
Wing  coordination 


10.  REQUESTING  COMMAND:  APPROVAL  11.  SUPPORTING  AGENCY:  APPROVAL 
SAC/TAC/USAFE  SM/ALC 
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File  Designation 
axxx 

axxx.P 


axxx.M 


axxx . K 


axxx.R 


File  Content  and  Structure 

File  series  name:  a  indicates  aircraft  series; 
xxx  is  change  number. 

CHANGE  STATEMENT  —  File  is  for  insertion  of  a  change 
statement . 

TITLE: 

CHANGE  REQUIREMENT: 

CURRENT  MECHANIZATION: 

OBJECTIVE: 

NOTES : 

STATUS : 

MECHANIZATION  —  A  narrative  which  is  source  data  for 
update.  Note  if  change  as  mechanized  is  different  from 
requirement . 

DATE  OF  LAST  UPDATE: 

DESCRIPTION: 

KEYINS  —  For  generating  addendum  tapes.  Machine  language 
code  for  patches  entered  prior  to  executing  a  compiled 
OFP.  Assembly  language  statements  are  not  required  but 
provide  design  interpretation  of  ML  code.  Note  required 
General  Navigation  Computer  and  Weapons  Delivery  Computer 
cues . 


$GNC  -  KEYINS 
LOC  IS 


(address) 


(revised 
ML  code) 


WAS 

(old 

ML  code) 


CORRESPONDING  AL  CODE 


SEND 

$WDC  -  KEYINS 
LOC  IS 

SEND 


WAS 


AL  CODE 


REASSEMBLY  —  Similar  to  KEYIN,  but  used  to  reassemble  a 
program. 

SGNC  -  REASSEMBLY 

(Exact  card  image,  punched  cards  format  previously  used 
for  reassembly) 

SEND 
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File  Designation 


axxx.I 


File  Content  and  Structure 


axxx.F 


axxx.G 


TEST  PROCEDURES  —  Step-by-step  test  procedure  to  checkout 
a  change. 

FLIGHT  TEST  REQUIREMENTS  —  Contains  information  for  flight 
test  of  OFP  change.  Contains  summary  of  change  and 
requirements  for  test  execution  (digital  channels,  test 
parameters,  success  criteria,  et.al.). 

GLOSSARY  —  List  of  any  new  labels  or  mnemonics. 
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index 


3 

DOCUMENTATION  STANDARD  FOR  PROGRAMS 

it 

DOCUMENTATION  STANDARD  FOR  SUBROUTINES 

5 

DOCUMENTATION  STANDARD  FOR  LIBRARY  SUBROUTINES 

6 

EXAMPLE  OF  PROGRAM  DOCUMENTATION 

9 

example  OF  SUBROUTINE  DOCUMENTATION 

1C 

EXAMPLE  OF  LIBRARY  SUBROUTINE  DOCUMENTATION 

1  0 

USER'S  GUIDE  PROCEDURES 

FXamPLF  OF  USER'S  GUIDE 


feasibility  study  procedurfs 


example  OF  FEASIBILITY  STUDY 


documentation  standard  i 

PROGRAMS 


C  r 

ci  external; 
ci 

_ai _ 

CI 

,  CI  -"£*A"«S  „ 


«  LIST  ALL  EXTERNAL  SUBROUTINES,  FUNCTIONS  AND 
data  FILES  ACCESSED  8T  The  PROGRAM  and  their 
_ LOCAUQiiL. _ 

t  INSERT  fQMMEKTS  TO  DEScRlRE  DATA  STRUCTURES  ANp 


ci 

r* 


UNUSUAL  PROGRAMMING  TECHNIOUES  and  REQUIREMENTS. 

_ thfSE  PfiMHF nt s  SHnmn  contain  any  information _ 

necessary  to  understand  the  program. 


_L. 

CO  USER'S  guide 


USER'S  GUIDE  IN  THE  SOURCE  LISTING  IS 


NOTE t  DEScpIpTlVE  COMMENTS  SHOULD  RE  GENEROUSLY  USED  THROUGHOUT  The 


> OUR CE  CODE  Tp  PE SCRIBE  NhaT  IS  HAPPENING. 


OTHER  DOCUMENTATION  NEEDEOl 

SOURCE "i'TSUng,  EITHER  8080  UR~"  aSSFMPLEO 

_  _ _ US_E_R'S_GUJDE _ 

LOCATION  OF  jorstreams/css  FILES  or  macros 
_ ASSOCIATED  NITH  the  program _ 
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I 


document  at i on  standard  2 
SUBROUTINES 


_ CM— TlLLE _ l. 

CH 

CM  Ok  1£  of.  la s t  .CMANSE.I. 
C*< 

_ cm  programmer _ l 

cm 

__Cr_EF?LANiLT10!i _ L 

CF 

CF  Pa*AHE TIPS _ t 

CF 

CF _ _ 

Cl  EXTERNALS  I 

__CI _ 

Cl 

_JC.J _ . _ 

Cl  Remarks  1 

__C1 _ 

Cl 

__fl _ 


T  I  T L F  OF  8LIRRQ1JT  T  NF 


J Tate  WK.AT.  THE  SUBROUTINE  PDF _ 

DEFINE  VARIABLES  WHICH  ARF  PASSED  TO  AND  FfiflM 
THE  SUBROUTINE, 


LIST  ALL  EXTERNAL  SUBROUTINES,  FUNCTIONS  ANo 
DATA  FI LES  ACCESSED  BY  THE  SUBROUTINE  OR  which 

call  this  subroutine. 


INSERT  COMMENTS  TO  DESCRIBE  data  STRUCTURES  and 
UNUSUAL  PROGRAMMING  TECHNIQUES  AND  RFPUI Rf MfMTS 
THESE  COMMENTS  SHOULD  CONTAIN  ANY  INFORMATION 
NECE SSA RY  TO  UNDERSTAND  THE  SUBROUTINE. _ 


NOYEi  DESCRIPTIVE  comments  should  be  CFNEROUSLY  USED  throughout  THE 
_ SOURCE  CODE  To  DESCRIBE  *HAT  IS  HAPPENING. _ 


OTHER  'DOCUMENTATION  NEEDED! 


SOURCE  LISTING 


I 


documentation  standard  3 

LI0RARV  ROUTINES 


NOTEi  DESCRIPTIVE  COMMENTS  SM0U1.0  BE  GENfROUSuv  USED  THROUGHOUT  THE 
_ SOURCE _CODE  TO  DESCRIBE  WHAT  IS  HAPPENING. _ 


example i  program  documentation 


cm 

_x 

CM 

_££.  JLX-RLA  M  A.i1  PiL 
CF 
CF 


CF 

_ C.F _ 

CF  OVERVIEW 


THIS  IS  A  PURGE  PROGRAM  EQR  USE  BY  CONFIGURATION 
MANAGEMENT,  the  PROGRAM  will  REQUEST  a  Pack  number 


NOT  ACCESSED  WITHIN  THE  PREVIOUS  7  DATS, 


PROGRAM  PACKPURGE l 
N' 


WHILE  PACKPURGE  NOT  COMPLETE 


_5P _ 

_  Cr _ 


CF 

I  variables 


ci 

_ ci _ 

CI 

_fj _ 

CI 

XTERNALS 


CI 

_CI _ REMARKS 

CI 

_ El _ 

CI 


THEN  ELIMINATEAREA» 
END. _ 


i  parlst  is  the  parameter  list  and  buffer  area  for 


sdasave 

elist  is  the  pa rameter  list  FOR  The  SYSTEM _ 

ELIMINATE  ROUTINE 


TH E  PR OGR_A M_ IS  COMPILED  AS  A  FORTRAN  PROGRAM  FOR 
EASE  OF  I/O, 

DUE  TO  THE  INTERNAL  OPERATION  OF  VULCAN,  TMI $ _ 

PROGRAM  MUST  BE  RUN  AS  *ACUTIL  IN  ORDER  TO 

utilize  the  svstem  routine  sdasav 


TO  EFFECT  THIS  The  PROGRAM  SHOULD  BE  EXECUTED 

_ BY  A  JOB  S TREAM  FILE  WHICH  R£NaMeS  ACUTJL  TQ 

TEMP,  PACKPURGE  TO  AC'JTIL,  EXECUTES  *CUTK 
AND  UPON  COMPLETION  RENAMES  ACUT 
PACKPURGE,  TEMP  TO  ACUTJL. 


WRITES, ROQ) _ 

FORMAt ( *  ENTE*"  PACK  •  TO  BE  PURGED") 

RE AO ( 3,BOI)  IPACK _ 

FORMAT(IJ) 

WRITE  C3,B02)  IPACK _ 


FORmaT(?X,I1) 
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6 


STOP 


j$e  - 

OLTrsT  BLOK  1 

J>a»LST  BLOK  2H _ 

RUST  BLOK  1 

_JLL  1S_1_J3  L  0  k_  J _ 

ARCNT  BLOK  1 

TMA _ IPACK _ 

TAB  PARLST+0 
TLO  £ARLSI _ 


BLJ 

-DATA. 

SDASaVE 

1 

FIRST  CALL  TO  DASAVE 

FUNfTTON  OODF  TU  C.FT  41  1  aRFaS 

— 

BO? 

_T£M 

BLIJ 

SOE 

DONE 
AP.CN J_ 

ST!ME 

7 

NO  AREAS  EXIT 

NiLMafR  OF  A  Rf  a  RLOCKS  RF  ThRNF  0  •  20  WORhS/Bl  flpK  _  _ 

GET  TODAYS  DATE 

SUBTRACT  7  nAYS  _ 

Ml  OOP 

TEM 

Rl  .1 

POATE 

GTaRra 

INITIALIZE  PURGE  DATE 

SFT  K  RFC.TSTfR  TO  aRFa  HI  OrK 

BOZ 

I1> 

DONE 

6jK 

NO  MORE  AREAS  TO  PROCESS 

CHFCK  tf  data  fti  f  or  program  FIIF 

BON 

BLJ 

MLOOP 

OLTEST 

PROGRAM  file  get  NEXT  APEA  BLOCK 

CHECK  IF  OOOOSYST  QUALIFIER 

BN* 

BLJ 

MLOOP 
_ ACCESS 

YES,  GET  NEXT  AREA  BLOCK 

_ _ CHECK  LAST  ACCESS  ...  . 

BON 

BLJ 

m 

WITHIN  7  DAYS  GET  NEXT  AREA  BLOCK 

TO  LONG  ELIMINATE  IT 

* _ 

HUC 

GET  NEXT  AREA  BLOCK 

GETAREA  ROUTINE 


«sgsaasssssa«gg 


ON  ENTRY  TO_THjS_RnU_T 
POINTER. 

SUBTRACT  _20_  fAREABLOCK  SIZE), 


■NT  BUFFER 


JF  NOT  POSITIVE  DAC ALL  ELSE  MOVE  POINTER  To  K  REGISTER  *  RETURN, 

_  D_A  C  *LU _ 

CALLS  IDASAVE. 


Tr ANSI  ERS  RUFfER  COUNT  TO  ARE  ACQUNT .  _ 

returns  to  mainline  ip  nothing  iv  pufffR  i.e  done. 
ELSE  RE-ENTERS  ge t area. _ 


GETAREA 


OACALL 


AOM  -2V  _  _  MOVE  POINTER  TQ  NEXT  AREA  DATA  IN  BUFFER 

DAC  ARCNT'  "■  ADDRESS  OP  LOCATION  TO  ADD  TO 


BNP 

OACALL 

BUFFER  COMPLETELY  PROCESSED  GET  NEXT  BUFFER 

TMK 

sue 

arcnt 

0,J 

MOVE  POINTER  TO  K  REGISTfR 
rfturn  TO  MAINLINF 

TLO 

BLJ 

PARLST 
Idas* ve 

GET  ADDRESS  OE  PARAMETER  LIST 

call  system  routine 

data 

BN? 

0 

sao 

NOT  THE  FIRST  CALL  SO  0  HERE 

PROBLEMS  SEND  ERROR  MESSAGE 

TEM 

BOZ 

ARCNT 

BUCOJ 

move  buffer  SIZE  TO  ARCNT 

ALL  DONE  RETURN  MITH  ZfRO  FLAG  SFT 

BUC 

GTAREA 

GO  SET  POINTER 

17a 
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ELIMINATE  ROUTINE 


_ muiuumaii _ _ 

MOVES  ARFANiHE  AND  QUALIFIER  PROM  BUFFER  TO  IFLIMINaTF  PRAM  LIST 
ELIMINATES  file 

-RETURNS- J-O-JUIN. _ 


TMD  0,«  SET  APEANAME  FROM  BUFFER 

-IRM _ EULSJ _ PUT-IN  PRAM  list _ 

TMD  S#*  GET  QUALIFIER  FROM  puffer 

_TpM  _f LlSlt? _ PUT  IN  PRAM  LIST _ 

BN7  *41  PROBLEM  SEND  ERROR  MESSAGE 

BUC  O.J _ RETURN _ 


ACCESS  ROUTINE 

_ «  s*  ■  ««»tt  n»»« _ 

GETS  LAST  ACCESS  DATE  AND  PURGE  DATE. 
SUBTRACTS  PURGE  date  FROM  ACCESS  date. 
RETURNS,  _ 


CCESS  T_ME  1 7 » M  GET  LAST  ACCESS  DATE 


TMa  HTIHE _ GET  PURGE  DATE 


BUCOJ 

S*E  SUBTRACT 

BUC  O.J 

IEND 

i 

C 

c 

THF  FOLLOWING  OTSPLATS  error  MESSAGE 

FOR 

*pasave  error 

c 

c 

40 

400 

WRITE  C3»  4001 

FORmaTC*  ERROR  IN  SdaSaVE  routine  contact 

PROGRAMMER") 

C  GO  TO  SO 

c 

c 

c 

the  FOLLOWING  displays  ERROR  message 

FOR 

SELIM  ERROR 

c 

4! 

WP!TE(3»41<jJ 

410 

c 

FOPmaTC  ERROR  IN  SELIMJNATE  ROUTINE  CONTACT 

PROGRAMMER") 

C 

c 

~c~So 

f  51 

COMMON  EXIT  LOGIC 

REWIND  10 

PEAD(10#500)VARIABLE  LIST 

C 

IF (EOFJGO  TO  60 

W»ITE(6i 50?) VARIABLE  LIST 

EXAMPLE!  SUBROUTINE  DOCUMENTATION 


SUBROUTINE 

CM 

gtdate(temp) 

CM  TITLE 

..  CM  _ 

I 

gtdate 

CM  date  OF  LAST 
CM 

CHANGE! 

8  NOV  78 

CM  programmer 

CM 

I 

M.TAVLOR  (  J.CLAAR 

BEVTSION  <  »  N-  TEAGUE _ 

CM 

CF_  EXPLAN  A_T ION 

«  THIS  SUBROUTINE  CONVERTS  AN  alPLHaBETIC 

MONTH 

CF 

.  Cl _ 

name  to  a  numeric  value,  thirteen  days 

ADDED  TO  THE  DATE  TO  ALLOW  FOR  CHPCKlNC, 

ARE 

PDR 

CF  DELINQUENT  Task  REQUESTS.  CROSS-OVJR  TO  The 

-C£ _ NEXT  MONTH  ANO/QP  YEAR  IS  TAKEN  INTtf' ACCOUNT 


CF 

-Cl.  PARAMETERS-. . . I  TEMP  .  ALPHANUMERIC  INPUT/DUTPUT  OF  DATE, 


Cl 

FORMAT  I 

Cl 

Cl  EXTERNALS 

1  CALLED  BY  MAIN 

-Cl _ 

_ LOCATED  IN  TRISHA  IN _ 

Cl 

'T  remarks  _ _ «  pates  will  not  be  converted  rfyqnp  the  year  1999 


C 

DATA  DEFINITION 

INTEGER  TEMP(3),V0ATEU2.2) 

C 

COMMON  /IPATE/YDATE 
end  DATA  DEFINITION 

c 

get  NUMERIC  OATE  EOR  test  in  CALLING  ROUTINE 

DO  10  1*1.12 

IF (TEMP(2) .EQ, TOATEfl* 1 3 )  GO  TO  20 
.10 _ C.O N  TINUE  _ _ _ _ 


"RITEI3. 1 Oy 0 )  TEHP(2) 

1000  FORMAT C10_M0NTH  GIVEN  (  1  Aa .  1  )  IS  WRONG  ENDING  SESSION') 


c 

call  exit 

SET  alpha  month  TO  NUMERIC  MONTH 

20 

TEMP ( 2 ) *  I 

-C _ 

ADO  IN  13  FOR  TWO  WEEK  CHECK 

c 

TEMP(1)«TEMP(1)»13 

CHECK  TO  SEC  IF  IT  IS  INTO  ANOTHER 

MONTH 

C 

IF(TEMP(1).LE.V0ATEfI.2))  GO  TO  9999 

YES  SUBTRACT  OUT  FOR  DAYS  INTO  NEK  MONTH 

TEMP(t)*TEMR(n-YDATE{I,2> 

C _ . 

INCREMENT  MONTH  COUNTER 

C 

TEMP(2)»TEMP(2)tI 

CHECK  TO  SEE  IF  INTO  NEK  YEAR 

IF { TEMR (2) .IE • 1 2)  GO  TO  9999 

400  TO  YEAR  COUNTER  (HILL  NOT  WORK 

FROM  1999  TO  ?000) 

c 

TEMP(3)*TEMPC3)M 

CNO  OF  OATE  ROUTINE 

9999 

RETURN 

ENO 
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EXAMPLEl  LIBRARY  SUBROUTINE  DOCUMENTATION 


CM 

CM 

entry  points  ... 

JU1  rtn 

CM 

CM 

LIBRARY  NAmE_ 

I 

OFPLIB  . 

CM 

CM 

date  of  last  change 

i 

R  MAY  7 7 

CM 

programmer 

i 

KARL  H  HASS 

CM 

CP 

explanation 

l 

THE  BUFFER  STARTING  AT  IRUFF  AND  FOR  NCHaR  BYTES  t ONG 

CP 

CP 

is  scanneo  looking  for  a  valid  date  ano  time  in  ascii. 

THE  OATe  IS  CONVERTED  TO  A  BINARY  K'fjRn  *N0  THE  T T ME  IS 

CP 

CP 

CONVERTED  TO  ANOTHER  binary  WORD,  the  APPROPRIATE 

STATUS  IS  RETURNED.  THE  date  CAN  BE  either  IN  TNTFRnAT 

CP 

CP 

(E,G.  84/01/77)  OR  CONVENTIONAL  C2«  Jan  77)  OR  JULIAN 
177.024),  TIME  IS  in  HH|MM,SS  AND  IF  NONE  I£  GIVEN 

CF 

CF 

THEN  12t00  too  IS  ASSUMED. 

CP 

CF 

overview 

i 

SCAN  THE  BUFFER 

IF  TmF  FORM  IS  JULIAN 

CONVERT  THE  DATE  TO  BINARY 

CONVERT  THE  TIME  TO  RINARV 

CF 

CF 

return 

IF  THF  FORM  IS  DO/MH/YY  OR  DD/MMM/YY 

CP 

CP 

IF  THE  YEAR  IS  LEAP  year 

IF  THE  MONTH  rs  LATFR  Than  FEB. 

CP 

CP 

ADD  1  DAY  TO  TOTAL  DAYS  IN  DATE 

CONVERT  DATE  TO  BINARY 

CP 

CP 


CONVFRT  TINE  TO  BINARY 
RETURN _ 


CP 

ci  parameters 
c: 

ci_ _ 

ci 

Cl _ 


j _ INPUT  t 


IPUFP  -  BUFFER  start  ADDRESS  “here  ™e  d*Te' 

_ TIME  IS  LOCATED _ 

NCHAR  •  length  in  BYTES  OF  IBUFF|  I«  format 


CI 

CI  _ 

CI  ' 

CI _ 

CI 

ci  externals 


OUTPUT! 

IRjN  »  IBINtn  IS  B1NARY_  date 


I8INI2)  IS  BINARY' TIME 
ISTaT  -  STATUS)  RANGE  «6  -  0»  14  FORMAT 


CAULS  PSCANt  LOCATED  IN  SYSlUSER  LIBRARY 


:i 

‘I  REMARKS 

CI 

Cl 


after  calling  julbtn,  subroutine  Julian  must  be 

CALLED  TO  CONVERT  The  BINARY  DATA  to  JULIAN 
RURmaT,  leap  year  CALCULATIONS  kill  BE  INCORRECT 
hEGINNJng  WITH  LEAP  year  1960. 


.prog  julbin 
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to 


SUBROUTINE  JUlBlNflBUFF, I8IN.NCHAR, 1ST AT) 
r 


C 


['iuu)iuau!iitcnrAniiuRAn  uu  ■ 


_DilA- IH0N1H/J Jan.  *4-’ 

*  *hav  »,'Jiin  ','Jul  '#'aug  ' 

•  'SEP  '.'OCT  1 . *  NO 


-OAT A--1DEC/  '  .. _ Uj-irOLDHy..1.  l _ U _ 

DATA  IDFLTh  /'/  '/ 


FINDING  OUT  in  hh*T  FORM  ThE  BUFFER  IS  IN 

~CALL  FSCAN('SCINIT',NCH19#IBUFF) 

CALL-?SC*N('tLiNixJJJ.OELI^iJRttAJ _ 

CALL  FSCAN{'GT0ISP',IPISP) 

.CALL_F  SCAN ( il £j( IJLiU EAT  tL.ENG.TJlj _ 


If  THE  FQBw  is 
IF  (LENGTH.  ,E0_^ 


IN  JULlANl 


IR.DAYJ 


_FO_RM  MUST  NON  BE  IN  DAY  MONTH  YR _ 

02  DEC  ?5 
02/12/7 


CALL  PSC*N( .STdISP' ,10ISP) 

CALL  F  SC  AN  (  •  NUMPER1 1  IDA*. NNt'M, LENGTH) _ 

IP  ( I D A Y  . GE.  32  .OR.  IDA Y  ,LE,  0)  GO  TO  PRO 


IF  ThE  FORM  IS  IN  DD/nm/yy  (02/12/75) 


CALL  FSCAN(  'GTDISPMPISP) 

CALL  FSC AN ( 'NUMBER' . INQNtNNUH, LENGTH) _ 

IFflMON  ,LT,  0)  GO  TO  2 

IF ( IMON  .eg*.  0  .OR.  I HQN  ,GT.  12)  GO  TO  99t 
ITEXT(I)  a  I honTH  (IHON) 

GO  TO 


IF  the  FORH  IS  OD  hmh  YY 


DEC  7 


CALL  FSCANCSTQISP'.IPISP) 

CALL  f$can( ’fExT', ITEXT, LENGTH) 
IF (LENGTH  .ne.  3)  GO  To  9P1 


CALL  FSC AN ( 'NUMBER' . I YP.NNUH, LENGTH) 

If  (I.YR^  ,GT.  po  .OR.  IVB  ,LT.  0  )  GO  TO  PP 


CONFiDOCOUIDE.HAN  ..... 
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83 

1 

I  ‘!'i  'L  -‘flpv^a  7 at itl^ r  ■ 


c 

DETERMINING  IE  YEAR  IS  LEAP  YEAR 

149 

tea 

c 

1S1 

DO  5  J.1.20 

142 

REAP  ■  0* J 

155 

IFt  IYR  .EQT  HEAP)  GO  TO  XO 

1 4a 

s 

CONTINUE 

15S 

c _ 

c 

non-leap  year  calculations 

157 

_C. 

14R 

DO  10  I  •  1# 12 

159 

lECITEXT(l)  .EQ.  IMONTHfl))  GO  TO  20 

1  60 

10 

CONTINUE 

161 

GO  TO  99» 

162 

20 

NDAYS  a  ITABLE(I)  ♦  IOAY 

163 

TYR  a  IYR  *0**16! 

164 

IRIN(1)  a  IYR  «  NDAYS 

165 

GO  TO  BO 

1  66 

C 

167 

C 

LEAP  YEAR  CALCULATIONS 

168 

C 

169 

SO 

DO  40  I  *  1.1? 

1  TO 

IF(ITEXT(1)  ,EQ.  IMONTHdl)  GO  TO  SO 

171 

00 

CONTINUE 

17? 

GO  TO  991 

173 

.  50.  . 

IFt!  .GT.  2)  IOAY  a  IDAY  ♦  1 

174 

NDAYS  a  I TABLE ( I )  ♦  IOAY 

175 

IYR  a  IYR  *(2**161 

176 

IBIM11*  IYR  ♦  NDAYS 

177 

GO  TO  80 

178 

c 

179 

c 

IF  THE  DATE  IS  IN  JULIAN  FORMATf YR.DAY) 

180 

c 

181 

70 

CALL  FSCAN(»3T0ISP'.IDISP) 

182 

CALL  FSCAN('STCHARMDEC) 

183 

CALL  FSC AN( •NUMBER*. I YR.NNUM, LENGTH) 

184 

IF ( I YP  .GT.  .99  .OR.  IYR  ,LT.  0)  GO  TO  092 

185 

CALL  FSC AN (•  NUMBER*.  IOAY, NnUMRENGTH) 

186 

IF ( IOAY  .GT.  366  .OR,  IDAY  ,LT,  0)  GO  TO  990 

187 

IBIN(i)  ■  IYR  *  (2**16)  ♦  IDAY 

188 

C 

189 

C 

PICKING  UP  THE  TIME  (HRjMIMiSEC) 

190 

C 

191 

00 

CALL  PSCAN(*STchaR'.ICOLON) 

1*2 

call  FSCAN( 'NUMBER* .INR.NNUH, LENGTH) 

193 

1F(IHP.LT.  o  .OR.  IHR.GT.  24)  GO  TO  993 

194 

CALL  F3CAN( » NUMBER' #HIN,NNUN,LENGTH> 

195 

IP (MJN  ,LT.  0  .OR.  MIN  .GT.  60)  GO  TO  994 

156 

CALL  F3CAN{ *  NUMBEft ' , I  SEC. NNUM. LENGTH) 

197 

IF ( I SEC  ,LT.  0  .OR.  ISEC  .GT.  60)  GO  TO  99S 

198 
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1 8 1 N  ( 2 )  ■  36000  *  I HR ♦  600  •  HIM  6  10  *ISEC 

-IS1AI  1-0 _ 

RETURN 


DEFAULT  Of  NOON  FOR  the  TIME 


IBIN(2)  a  36000*12 
RETURN 


ERRORS  IN  BUFFE*  PASSED 


INVALID  DAV  a  -1 

INVALID  MONTH  a  -2 _ 

INVALID  VEAR  a  -3 

INVALID  HR  n_-9 _ 

INVALID  MIN  a  -5 

N 


RETURN 

_?R.3__-I£lL*R_*IO^_- 

ISTAT  a  -0 

_ -RETURN _ 

-»<?«  ISTAT  a  -5 
RETURN 


90S  ISTAT  a  -6 

_ return _ 

END 
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USER'S  GUIDE  PROCEDURES 

1. 

PURPOSE 

G< v#  «  Qft *• r • 1  d®seMot<oh  of  tH#  Dfoqr*w  stfttfng 

it*  purcoae  and 

a* 

INPUT 

Oe*eri ha  the  In But _ Including  format* _ eantant# _ input  martin. _ anri 

eequenelng. 

J. 

OUTPUT 

De*eMbe  the  output  including  format,  content#  and 

output  mediae 

4, 

OPERATING  PROCEDURES 

L<*t  the  atep  by  step  procedure*  reoulred  toi 

1,  Ini 1 1  at*  the  Program, 

2,  Maintain  operation. 

3,  Terminate  end  raatart  the  Program, 

Give  an  operational  e**mpla. 

5. 

RESTRICTIONS 

De*eMfc>«  *ny  limitation*  such  a*  *1**  of  Innut,  computer  eroce**or 
us#dj_  «y» t__«n_  ip»et  required#  ate. _ 


6.  APPLICABLE  ERROR  MESSAGE 


4-PI  ASSEMBLES  'USERS '  SUIOE 


-  J  . _ PJJ  REUSE - 

_ The  malor  Ob leet i Vs  of  the  4-PI  Assembler  rewrite  contact  la  to _ 

allow  complete  Processing  of  4-PI  programs  »t  SMALC,  At  this  time, 

_ _ A_JUrnt**.i  no  veral  on  of  the  astamblar  ajli  «t»_f  or.  iin. _ This  version 

accepts  a"  Ordinary  4-PI  Aa(enb1sr  Input  file  and  creates  from  it  a 

.  svntaxed  «nd  eroas-refareneed  listing  of  the  Input. CQmp.le t e 

documentation  on  the  use  of  th#  assembler*  rater  to  the  IBM  CP-2 
_ and  4-Pt  manuals, _ _ _ 

2.--  INPUT- _ 

_ tbLs.  assembler  aceeots. the  Same. Input _ as _ Lbs _ Ogden  assembler,  .with _ 

the  following  exceptional 


1.  Th*  JCL  cards  are  not  needed  and  *re  Ignored  If  found  In  the 

_ _ _lapui_iiie, _ 

flleneme.  Defaults  are  set  to  the  user  volume  and  no  extension, 

_ _T._hf_jn.clud ed  fl.ies."ust  bf-pretent  ,pn.  t‘>e.-Ifltar.gf ? a.  svster  and _ 

all  member  n,r»  cards  must  be  deleted  from  the  date  sets, 

OUTPUT 

The  outout  consists  of  the  assembly  listing  Including  error  messages, 

__  warning  messages,  error  summary.  Input  file  description,  cross  re- _ 

ferenee  dictionary,  e*ter«al  av*b©'  d*et1onary,  special  remarks 
_  c  a rfls.L  en.d_t  ab It_ .0  i  _ca n tan.tj, _ . — _ — 

4,  OPERATING  PRQCEOuPES _ 

4 Ln Lt!  jJ Preparation  Procedures _ 

Bef  ore_  using  the_  essembler  for  the  first  tine,  <t  Is  necessary _ 

to  oreoare  the  lnDut  fl'es,  It  Is  assumed  that  the  main  Input 

module  Is  already  located  on  an  Interdata  disc  each,  However, _ 

since  meat  of  the  E*BIKS  reside  as  date  sets  1«  libraries  at  Ogden, 

_ the  user  must  retrle vs  these  oata  sets  for  use  on  the  Interdata. 

A  eeDarete  file  Is  needed  for  each  EXBl*,  end  the  "ember  name 

e a r d s_  " ust  b e  deleted .  T>ese  files  may  be  give"  any  Interdata _ 

filename,  minimal  te*t  editing  of  fl'es  Is  desired, 

the  above  files  should  be  named  using  tbs  user  volu"f, _ 

the  name  from  the  INCLUDE  card,  end  no  extension.  If  these 
_  defaults  are  not  used,  the  user  must  modify  any  INCLUDE  card  In 

the  eoures  to  Indleett  the  new  filename. 
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#.2  OPERATION 


The  <I«M  *m»bU|i  1*  •  non*lntertet  1  v*  te*l<,  It  It  celled  by 
_ t.b*  _is  LJ  oyi _ _ _ 


A.8hp_i  fj ltaaatl _ < _ Li  tenaweg 

* 


A 


wh*r* 

f11en*me2  It  the  uter'»  output  f I '• 


Option*  for  th«  output  file  trei 


1,  filename  *  output  go«a  to  the  toeeifled  file 

2«...P _ rOutPut  l_a._d  1-tB.I  eyed  Ort..lh.t...CRT  *t  reen _ 

},  t  *  output  got*  to  •  null  device 

A, _ tltak _ ■  output  aa.l  to  the  utef.1t  default  Hat  file 

l  _ End  of  tatk  atatua  It  dltoltyed  on  the  CRT  mm  «t  follow*! 

_ f.N0_Pf_T#8JS_ft _ Aj*egfeJAd_w1.t.h  jw  errata _ 

END  OF  Task  2  Attembled  with  warnlnga  only 

END  OF  TASK  1  Attenhled-ulth  errort _ 

Etpnpl  »l  ...The.  fotlpwlnp  it  a  thort  ananpl*  of  a  <t»PI  progra"* 

•  nd  a"  INCLUDE  nodule  with  comment  a  I 

-  S0UBCE 

//RiHlbGNSJOB  ('AlSa.'.lO.MKEOr  1  QFP  ♦  >  CLASSlE _ 

//SYliSCR.SVSIN  OP  * 

_//CFASMS.INCAPD_J>n_  * _ 

ASSEH  A.NSSG 

The  above  cerda,  *11  JCL  and  the  ASSEM  ea^d  are  treated  at 
e pmmgntB  end  are  Ignored. _ 

entry  ov_y _ 

E*TRN  VSh'lFT 

gambol  _exbu_ _ 

incluoe'  gambol 


Module  GAMBOL  mutt  haw*  been  brought  bae*  fro*  Ogde"f  tebarated 

Jnto  tt t  own  filet  and  plteed  on  the  user1*  drfault  dltc « _ Ih.e_ 

filename  mutt  have  blank*  In  the  eat*n*ion. 


FCQP _ BS8H  l 


10616 _ E  *  BLK _ _ 

V  '  INCLUOE  FROHIOB16.SRC/G 
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lt> 


Module  10816  ha* **  been  fully  described  ••  residing  on  disc  PB01 
J»ith  extension  ,8BC/G, _ _ _ 


6j _ ERROR  MESSAGE. S _ 

_ Two  tybee  of  er  r_o_ra  ire  Indicated  bv  the  assembler,.  The  f  1  rat  di s» 

pl«ya  bad  file  I/O  to  the  CRT  »ctte"i  Qi vi ng  the  file  Involved  and 

_ the  i/q  status.  This  tvpe  Include*  errors  auch  as  assignment  errors 

f or  the  Input  oP  outout  file.  The  second  type  of  error  fa  for  syntax 

_ .errors  and  warnings^ _ These  aya  merged  Into  the  output  listing  and 

aooear,  beginning  in  column  2»  as  followsl 


*  WARNING  a  COLUMN  0  NOT  blank 

** ERROR  — »  3  MULTIPLY  OEflNEn  LABEL 

Warn  i_ngs  and  Errgrat _ 


Wa rni nps  i _ 

1,  SHORT  INSTR  DOESN'T  FOLLOW  A  SKIPr  COMPARE  OR  MODIFY  STORAGE 

2,  LONG  INSTRUCTION  GENERATED  IN  E*BLK 

3,  SHORT  INSTRUCTION  GENERATED  _ 

fl,  COLUMN  a  NOT  BLANK 

s._  SMirT  value  to  large  »■  mas  seen  set  to  maximum  _ 

6,  ENTRY  OR  EXTRN  DEFINED  BUT  NOT  USEO 


Ef rortt 


1,  ILLEGAL  OPCODE 

2,  _ ILL  E  G  *  I _ L  ABEL  JL^__LOCAU 

5,  MULTIPLY  DEFINED  label 


ILLEGAL  CHARACTER  IN  COLUMN  15 


L’llJf  l.lli 


,  UNDEFINED  LABEL  used 


1«1  «  ft  um  M  JJ  ij  4«! 


Fjjigyjjg 


UNDEFINED  set  or  eou  label 

Mi' 


It.  INVALID  SHIFT  VALUE 

_1?.  INVALID  INDEX  REGISTER _ 

13.  INVALID  HEX  MASK 

1°.  ILLEGAL  VARIABLE  FIELD  MttAl _ 

t5.  ILLEGAL  MACRO  Name  SPECIFIED 

0  nesting  excffds  id  levexs _ 


17.  MOPE  Than  io  parameters  USED 

_ 18*  INVALID  macro  argument _ 

19.  MACRO  Table  LIMIT  EXCEEDED 
_  2P*_  MACRPrJNalK,  EXpLK  must  appear  BEFORE  EXECITaBL 
21.  INVALID  IFF  OR  IFT  INSTRUCTION 

nvalid  go  to  operand _ _ _ 


23.  1NBLK  DR  EXBLX  DEFINITION  EXCEEDED  Maximum 

_ 2R»_DEC  OR  R£I  f>A.T_A  TRUNCATED _ _ _ 

25,  ILLEGAL  COMBINATION  OF  INBLK,  EXBLK 
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TC0PY2  Feasibility  Study 


_  i.  Problem _ _ _ _ _ 

- 1C0P V?  under  MTB03  will  not  prone* *  the  fjm  on  tlflll  ef»« t»H 

under  MTR02. 


2,  current  Implementation 


when  aceeaalng  tePea  cheated  under  HTR02*  TC0Py2  must  be  Implemented 
_in.no.he.ade r,.mc.dej _ *  u»e r  null  u«»r  tha  ADV  rnmn.nd  to  nnaltlan  th» 


taoe  at  the  correct  Hie, 


3,  Solutions 


t)  Hodlfv  TC0Py2  to  Ignore  th#  account  number  field  In  the  header 

- files.  _t>j  problem  me  d1«cua*ep  with  the  original  y»nf» inner 

who  oudoested  that  the  ehanoe  cou'd  be  eaally  Implemented, 


.Be«erjl...gae.r  would  ...  .  . .  . . .  . .  ... 

file  on  the  taoe  and  then  eroeeed  with  *  BEAD  commend, 
CO*  t.jU  L_bf .  30  m*n  houre  and  2U  machine  Knur., _ 


The 


The  time 


Jtl _ Uae  t he~cu nr*" t  lirPl erent at  1  on, _ This  reauiree  the  uaera  to  f1r«t 

use  the  INDEX  commend  to.dlaolay  a  Hit  of  aH  file*  on  the  taoei 
the  count  the  number  of  files,  Ineludlnp  hath  header  end  date 

j  i  1  . .  M  _  ...  inu  . _ -t  .  ..... l  _  .  _  i 4  j 


V - U-'.EU.  .’.'.'fc  '  P.B W...Z5 * 

file*,  and  u*e  the  ADV  command  to  advance  the  proper  number  of 
f  1  leal  then  switch  to  NpMEADEB  mode  and  proceed  with  e  READ 
Commons. 


3)  Recommendation* 


It  Is  recommended  th*t  TC0PY2  be  modified.  This  modification  will 
moke  t*De  file  acou1»1t1on  lea*  complicated  for  the  oencr*!  user. 
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PERSONNEL  DESCRIPTION _ DATE:  28  1979 

DESCRIPTION  OF  SKILL  LEVEL  AND  TYPE  (AF/CS/CONT)  OF  PERSONNEL  MAINTAINING  THIS  PACKAGE 

Below  is  the  official  position  description  for  a  GS-12  Electronic  Engineer 
(Computer  Systems).  This  description  outlines  the  basic  requirements  of  the  work 
to  be  done,  whether  performed  by  Civil  Service  or  contractor  personnel. 

I.  INTRODUCTION 

See  functional  statement  filed  in  Official  Position  Description  folder  and  the 
Sacramento  ALC  Organization  Directory  charts.  Incumbent  of  this  position  serves  as 
an  Avionics  System  Engineer  responsible  for  accomplishing  software  and  systems 
engineering  projects/tasks  for  avionics  embedded  computer  systems,  their  resident 
Operational  Flight  Programs  (OFPs)  and  their  support  systems  for  the  F-lll  and  other 
Sacramento  ALC  prime  aircraft  systems. 

II.  DUTIES  AND  RESPONSIBILITIES 

1.  Develops,  coordinates  and  carries  through  to  completion  blocks  of  work  of 
large  scope  containing  many  phases  of  which  two  or  more  phases  each  contain  several 
complex  features.  Plans  and  conducts  research,  development,  or  other  work  for  which 
precedent  data,  criteria,  methods  or  techniques  are  significantly  inadequate,  are 
controversial,  or  contain  critical  gaps.  Develops  or  originates  completely  new 
features,  in  addition  to  improving,  extending,  or  validating  currently  known  pre¬ 
cedents,  data,  methods  or  techniques.  In  accomplishing  the  above  incumbent  is 
responsible  for  the  development  of  modifications  and  changes  to  complex  aircraft 
digital  avionics  systems,  their  Operational  Flight  Programs  (OFPs),  and  laboratory 
support  systems  (e.g.,  the  Sacramento  ALC  F-lll  Avionics  Integration  Support  Facility 
(AISF) ) .  In  addition,  incumbent  is  responsible  for  the  investigation,  analysis, 
evaluation  and  reporting  on  avionics  system  performance,  problems  and  new  requirements 

2.  Develops  and  carries  through  to  completion  complex  changes  to  the  OFPs. 

Uses  the  F-lll  AISF  to  analyze  and  evaluate  OFP  requirements  in  order  to  develop 
optimum  implementation.  Investigates  potential  solutions  to  system  problems/change 
requirements  considering  tradeoff  analyses  involving  implementation  costs,  algorithm 
developments,  timing  requirements,  memory  size,  hardware/software  integration 
requirements,  support  equipment,  personnel  capabilities  and  limitations,  data  package 
development  and  overall  magnitude  of  the  effort;  and  translates  these  change  require¬ 
ments  into  engineering  specifications  and  tasks.  Designs  the  change  mechanization 
and  integration;  develops  the  programming  code;  and  debugs,  tests  and  documents  the 
results.  At  all  times  assures  aircraft  system  integrity  and  compatibility;  and  meets 
resource  allocations,  performance  criteria,  cost  and  schedule. 

3.  Establishes  formal  test  requirements  for  OFPs;  develops  and  implements  test 
plans;  conducts  detailed  tests  using  the  full  capabilities  of  the  F-lll  AISF  and 
instrumented  flight  test  aircraft;  and  analyzes,  evaluates  and  reports  test  results. 

4.  Serves  as  project  engineer  for  the  design  and  development  of  changes  and 
modifications  to  the  AISF  hardware/software  resources  and  other  avionics  support 
systems.  Provides  system  engineering  support  and  assures  compatibility  with  the 
aircraft  avionics,  digital  computer  complexes  and  OFPs.  Establishes  change  require¬ 
ments  directly  with  the  AISF  and  avionics  support  systems  users.  Prepares  change 
specifications  and  plans  and  schedules  the  complete  development  and  implementation. 

5.  Conducts  studies  and  evaluations  of  systems  in  acquisition  and  determines 
support  requirements.  Performs  2612  studies,  prepares  Computer  Resources  Integrated 
Support  Plans  (CRISPs)  and  participates  as  a  member  of  Computer  Resources  Working 
Groups  (CRWGs) . 
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6.  Prepares  contractual  engineering  proposals  and  associated  specifications 
and  work  orders. 

7.  Monitors  and  maintains  close  liaison  between  contractor  and  Air  Force 
activities  associated  with  the  engineering  support  of  digital  avionics,  embedded 
computer  systems  and  OFPs  for  Sacramento  ALC  prime  aircraft  systems. 

8.  Reviews,  evaluates  and  advises  on  the  effectiveness,  technical  adequacy 
and  suitability  of  work  and  proposals  of  others  related  to  digital  avionics  and 
OF-?  support.  Evalutes  more  complex  vendor  proposed  modifications  for  requirements, 
feasibility,  completeness,  accuracy,  cost,  and  operational  and  logistics  impact. 

9.  Consults,  coordinates  and  attends  conferences  with  other  service 
activities  and  higher  headquarters  on  matters  pertaining  to  avionics  OFP  develop¬ 
ment  and  support.  Makes  recommendations  to  higher  authority  for  changes  to 
policies  and  practices,  based  on  knowledge,  experience,  engineering  studies, 
observations,  and  reports  received  from  service  activites,  and  defends  Sacramento 
ALC’s  findings  and  recommendations.  Travels  to  contractor  or  other  government 
facilities  to  review  engineering  data  and  render  opinions  and  decisions  which  are 
normally  unreviewed;  maintains  liaison  with  other  government  activities  and  con¬ 
tractors  in  order  to  exchange  engineering  data  and  to  maintain  a  current  knowledge 
of  the  state-of-the-art. 

10.  Independently  determines  logical  approach  to  solutions  of  major  associated 
avionics  OFP  development  and  support  problems.  Carefully  weighs  the  advantages  of 
increased  systems  reliability,  maintainability,  etc.,  against  time,  cost,  com¬ 
patibility,  and  safety  of  flight.  Makes  and  evaluates  proposed  changes  to  the 
system  software  on  the  basis  of  established  hardware/ software  interfaces. 

Establishes  supporting  projects  with  other  engineering  personnel  and  directs  the 
integration  of  auxiliary  projects  toward  the  ultimate  objective.  Scope  of  project 
effort  is  broad  in  that  all  projects  consider,  as  applicable,  the  mission  of  the 
aircraft;  functions  of  associated  avionics  systems  (weapon  delivery,  navigation, 
reconnaissance,  radar,  instrumentation,  etc.);  communication/interface  requirements; 
flight  test;  computer  program  documentation  and  configuration  control;  and  vali¬ 
dation/verification  of  the  software.  Applied  research,  special  investigations, 
statistical  analysis,  etc.,  are  a  normal  part  of  the  incumbent's  effort  in  accom¬ 
plishing  his  duties  and  responsibilities. 

III.  CONTROLS  OVER  WORK 

Incumbent  is  under  the  supervision  of  the  Section  Chief  and  receives  technical 
direction  from  the  functional  group  engineers  and  other  senior  engineers  who  give 
assignments  in  terms  of  broad,  general  objectives  and  relative  priority  of  work. 
Extent  and  limits  of  assignments  are  mutually  discussed.  Incumbent  works  with 
considerable  freedom  from  technical  control  in  selecting  and  establishing  the 
proper  methods  for  attacking  and  resolving  complex  features  and  otherwise  carrying 
assignments  through  to  completion.  Controversial  policy  questions  are  resolved  by 
joint  consideration  with  the  supervisor  and  functional  group  engineer.  Completed 
work  is  reviewed  for  adequacy  in  terms  of  broad  objectives  of  the  work  and  for 
compliance  with  Air  Force  policies  and  regulations.  Decisions  and  recommendations 
based  upon  application  of  standard  engineering  practices  are  rarely  changed  by 
higher  authority,  except  for  reasons  of  policy,  public  relations,  or  budgetary 
consideration. 
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IV.  OTHER  SIGNIFICANT  FACTS 

1.  Fields  of  Engineering:  Electronic  -  552,  Computer  Science  -  302 

Aerospace  -  152 

2.  In  addition  to  an  extensive  academic  and  professional  knowledge  of 
scientific  and  engineering  principles,  it  will  be  necessary  for  the  incumbent  to 
possess  a  special  faculty  to  do  successful  applied  research  and  establish  authori¬ 
tative  criteria  based  on  sound  engineering  principles  used  within  this  section  by 
joint  consideration  with  other  engineers.  At  most  times,  the  incumbent  will  be 
responsible  for  several  projects  requiring  difficult  and  advanced  engineering  work 
of  a  high  degree  of  originality,  therefore  incumbent  must  have  a  thorough  and 
detailed  knowledge  of  avionics  digital  systems,  (e.g.,  inertial  navigation  systems, 
fire  control  radars,  stores  management  systems;  digital  controls  and  displays, % 
etc.);  aircraft  embedded  computer  systems;  real-time  operational  flight  software; 
laboratory  support  systems  to  include  real-time  simulation  systems,  host  computer 
systems  and  avionics  system  hot  mock-ups;  software  configuration  management; 
software  documentation;  OFP  testing,  evaluation,  verification  and  validation;  and 
aircraft  performance  and  operation,  specifically  in  the  areas  of  navigation  and 
weapon  delivery.  Must  be  experienced  and  knowledgeable  in  real-time  programming, 
mathematical  modeling,  computer  architecture  and  programming  languages. 

3.  Incumbent  must  possess  a  high  degree  of  professional  judgment,  skill, 
initiative,  planning  and  leadership  ability.  Also  must  possess  ability  to  maintain 
effective  personal  work  relationships  at  all  levels  and  to  justify  and  sell  his  own 
professional  viewpoints  in  conferences,  engineering  reviews  and  with  fairly  large 
groups  wherein  conflicting  points  of  view  are  represented.  Requires  an  Intimate 
knowledge  of  functions,  organizational  structure,  jurisdictional  responsibilities, 
etc.,  of  USAF  and  elements  thereof. 

4.  The  incumbent  of  this  position  must  be  capable  and  willing  to  perform  TDY 
travel  in  accordance  with  the  Joint  Travel  Regulation. 

5.  Supports  and  takes  affirmative  actions  in  furtherance  of  Equal  Employment 
Opportunity  in  all  aspects  of  personnel  actions,  with  special  emphasis  on  Upward 
Mobility  and  other  special  programs. 

6.  Position  requires  a  security  clearance  of  Secret. 

7.  Performs  other  related  duties  as  required. 

8.  Subject  to  call  during  off-duty  hours. 

9.  All  personnel  will  share  in  the  responsibility  for  a  sound  industrial 
safety  program.  Incumbent  is  required  to  comply  with  all  applicable  safety 
directives.  Unsafe  conditions  are  to  be  promptly  reported  to  the  immediate 
supervisor. 
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BUILDINGS: 

2 

10,800  ft.  of  standard  computer-type  facilities. 


DATE:  28  Sept  1979 


5  -aMs* we****—  ■'-- 


PREDICTIVE  SOFTWARE  COST  MODEL 

SOFTWARE  PACKAGE  CHARACTERISTICS  -  FACILITIES  (Conti _ DATE:  28  s 

COMPUTER  FACILITIES  (Type.  Quantity.  Application,  Cott  &  Usage) 

The  basic  equipment  in  the  F/FB-111  Avionics  Integration  Support  Facility 
is  as  follows: 

Cost 

!  Equipment  ($  million) 


Dynamic  Simulation  System  (Harris) 
System  and  Software  Engineering 

Flight  Test  Data  Reduction  (PDP) 

Off-line  Computer  Support  (Interdata) 

Integration  Test  Equipment  @  1.7x3 
Original  cost  -  $800K  each 

Subsystem  Testers  (11) 

Avionics  (loaned  out  of  spare  assets) 

F-lllF/Pavetack  Dynamic  Simulation 


5.1  (replacement 
cost) 

3.5  (replacement 
cost) 

12.9 


To  be  added: 
F-111A/E  Hardware 


Vendor  support  on  the  Harris,  Interdata  and  PDP  computers  costs  $308K/year 
plus  $126K/year  for  expendables  and  prototype  hardware  (split  50/50). 
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INTERDATA  8/32  System 
(Data  Reduction  and  MIS) 


2  Processors  1  megabyte  each 

8  40  mb  disc  drives  (4  switchable,  4  fixed) 

1  300  mb  disc  drives 
12  4  kb  Floppy  Drives 
1  Line  Printer 
4  Mag  Tape  Drives 
1  Paper  Tape  Reader 
1  Paper  Tape  Punch 
12  CRTs 

1  IBM  Selectric  Typewriter 
1  HP  Auxiliary  Printer 
1  Tektronix  Plotter 

3  ITE  (Integration  Test  Equipment)  Static  Simulator 


"ji  «*;  rwswi* 
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Harris/ 4  System 
(Dynamic  Simulator) 


2  test  stations 

2  ADAGE  (large  display  screen  on  test  station) 

6  processors  -  80K  each 

2  SAS  (Simulation  and  Switching)  Interface  between  Harris  &  test  station 

6  CMACs  (Computer  Monitor  and  Control)  Interface  between  4pi  computer 

and  Harris 

1  card  reader 

1  card  punch 

2  paper  tape  readers 
8  mag  tape  drives 

1  CDC  line  printer 

2  Versatic  printer/plotters 
11  C*T 

2  teletypes 
6  10  mb  disc  drives 

1  40  mb  disc  drives 

2  300  mb  disc  drives 
1  paper  tape  punch 
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DATE:  28  Sept  1979 


PDP  11/40  System 
(Flight  Test  Data  Preprocessing) 


16K  words  memory 
1  Dec  Writer 
1  Card  Reader 
1  1.2  Mbyte  Disc 

1  9-track  tape  drive 
1  Paper  tape  punch/reader 
3  8-channel  brush  recorders 
1  CRT  display 
1  Versatec  printer/plotter 
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TYPICAL  UTILIZATION  OF  HARRIS  COMPUTER  WEEK  OF  23-27  July  1979 

Time:  Mon  Tue  Wed  Thu  Fri  Sat  Sun 

0000  .  .  •  •  •  ... 

0100  •  •  •  •  •  • 

0200  .  .  •  •  •  ... 

0300  ■  •  •  •  •  .  .  . 

0400  •  •  •  •  •  • 

0500  •  •  •  •  •  ... 

0600  •  •  •  •  *  .  .  . 


U/  UVJ 

0800 

Harris 

Harris 

Harris 

(Maine) 

0900 

IV  &  V 

IV  &  V 

1000 

GD 

IV  &  V 

1100 

IV  &  V 

1200 

1300 

F 

IV  &  V 

F 

1400 

GD 

(Mod if  & 

1500 

Upgrade) 

F 

1600 

1700 

MMECS 

GD 

F 

GD 

(Backup, 

1800 

Archive, 

etc.) 

1900 

2000 

. 

2100 

• 

2200 

• 

2300 

2400 
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COMPUTER 

SOFTWARE  FUNCTION  ESTIMATE  SOURCE 

LINES 

INTERDATA  8/32 

SYSTEM 

166,957 

UTILITY 

42,841 

SPECIAL  UTILITY 

AGERD 

3,299 

4-PI 

6,764 

MDS 

2,525 

FLCL 

696 

PLOTTER 

4,754 

OFP  UTILITY 

13,286 

DATA  REDUCTION 

46,002 

287,124 

HARRIS 

SYSTEM 

292,953 

UTILITY 

34,494 

RJE 

7,410 

PLOTTER 

7,580 

OFP 

4,000 

ADAGE 

6,714 

SAS 

2,888 

SIMULATOR 

17,706 

CMAC 

13,674 

387,419 

PDP  11/40 

UTILITY 

5,177 

DATA 

22,619 

27,796 

Pages  C-53  through  C- 

71  provide  a  detailed  listing  of 

the  support 

software. 
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soft 


4  f  t 


t  i  f  t  r 


t  1  <’ 


CURPgNT  4 S  OF  t  as. U M79 


KEY! 


H 

I 

CO 
I  M 
T  I 
DEC 
N/C 
TE1' 
VE  = 
M4  JT 
FES 

GE*/°ES 


HARRIS 

IMEBOAT* 

GENERAL  f'Y^A^'ICS 
If-  HOUSE 

TEXAS  INSTPU“EMTS 

DIC-ITaL  FDUIPheuT  CORPORA!  I  ON 

NO  SOURCE  AVAILABLE 

TEKTRONIX 

VE»SATFC 

MAINTENANCE  RESPONSIBILITY 
GENERAL  RESEARCH 


INTEPDAIA  B/52 
UTILITY  SOFT aaRE 


CI  na“E 

SHP. 

puir» 

M  A  I  T 
RES 

EST 

SOURCE 

LI>'ES 

DESCRIPTION 

ACCOUNT 

IH 

IH 

299 

ImTERDATA  USAGE  report  GENERATION 

4maP 

IH 

IH 

"5. 

ALPHABETICALLY  LISTS  FILES  from  DISC  pack 

CAPS 

IH 

IH 

63R , 

converts  capital  TO  small  LETTERS  ano  VISA-VeRSA 

CARDIN 

IH 

IH 

162. 

HANDLER  fop  THE  CARD  RfADER 

COPYfIle 

IH 

IH 

765. 

COPIES  FILES 

COPYtaPE 

IH 

IH 

206. 

DUPLICATES  PUNCHED  TAPFS 

DDCPRD 

IH 

IH 

507. 

PULLS  DOCUMENTATION  FROM  SOURCE  FILES 

entry 

IH 

IH 

193. 

COPIES  DATA  FROM  HEWLETT-PACKARD  TERMINAL 

• 

CASSETTE  INTO  A  EIlF 

INDEX 

IH 

IH 

152. 

LISTS  ALL  OCCURRENCES  PE  A  CHARACTER  STRING 

• 

IN  A  FILE 

LlblNV 

IH 

lH 

R62. 

DOCUMENT  INVENTORY  PEPORT  GENtRATO0 

LINK 

IH 

JH 

513. 

LINK  BFTWEFN  THE  INTERDAU  and  HARRIS  CP“P07ER 

LIST 

IH 

IH 

220. 

LISTS  A  FILE  TO  THE  USER  TFRM1NAL 

MANHOURS 

IH 

IH 

2R1R, 

PERSONNMEL  UTILIZATION  REPORT  GENERATOR 

MICROFSM 

IH 

IH 

2119. 

REFORMATS  FILES  TO  THE  MICROFICHE  PROCESSING 

• 

FORMAT 

MTCOPY 

IH 

IH 

229. 

DUPLICATES  AND  VERIFIES  “AGNETIC  TAPES 

part 

IH 

IH 

6?6, 

COPIES  APT  FORMAT  DATA  TO  PUNCH  TAPE 

POINT 

IH 

IH 

1  55 . 

COPIES  A  FILE  TO  A  HEWLETT-PACKARD  AUXILIARY 

• 

PPJWTER 

PMNCHP 

IH 

IH 

10511. 

OIRECT  BIT  COPY  TO  PUNCH  TAPE 

READFILE 

IH 

IH 

5R6. 

GfNEOATES  A  FORMATTED  LIST  FILE 

RECOVER 

IH 

IH 

376, 

RECOVERS  FILE  PROM  BACKUP  TAPE 

UKAP 

IH 

IH 

152. 

LIST  FILES  FROM  DISC  PACK  BY  USE®  NUMBER 
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TSUInV 

T  M 

TH 

.  tOO». 

REMOVE 

1H 

IH 

.  212- 

RFSTqKE 

IH 

IH 

.  255. 

REQUESTS 

IH 

IH 

.  TJ5 

«F  hot  TF 

IH 

IH 

-  EM 

SHIFT 

IH 

Th 

.  173 

SORT 

IH 

I" 

.  230 

TaPEdIR 

IH 

IH 

.  200, 

TCOPy? 

IH 

IH 

.  a  a  u  3 

TE 

IH 

IH 

.  16257 

Terminal 

IH 

TH 

,  2  6  1 

tlist 

• 

IH 

IH 

TYPF 

IH 

IH 

.  2RR 

kRUE 

0 

IH 

IH 

.  22a 

* 

m  TH 

E  FOLLO 

*'ING  Cl ' 

ASSIGN 

IH 

IH 

.  "T 

datf 

TH 

IH 

,  6  8 

F TNDOA 

IH 

IH 

.  33u 

F  SC  A  N 

IH 

IH 

.  1  fl5o 

LISTING 

IH 

IH 

.  5aa 

RAN  0  C1  v 

IH 

IH 

.  15 

V I R  m  £  m 

• 

IH 

IH 

.  use 

****»ThE 

FOLLO 

»INC-  Cl 

•S  ARE  c 

A»Ean" 

IH 

IH 

.  I'M 

,EN0f*0 

IH 

IH 

.  R I 

,f NRVAR 

IH 

IH 

.  ®? 

tf NTfXD 

IH 

IH 

.  233 

.ENTvaR 

IH 

IH 

,  lao 

•FSCaN 

IH 

IH 

.  95 

FILE mG 

• 

IH 

IH 

.  1 2P3 

F I  NOT  X 

f 

IH 

IH 

.  no 

M  VC  HP 

• 

IH 

IH 

.  “5 

total 

• 

• 

.  a;»sai 

'AGNEUC  TAPE  INVENTORY  l-EB0RT  GENEmaTIP' 
SEPARATES  CP"MEMS  FRO"  SOURCE  CODE 
REPLACES  COHUffJls  JIJTO  SOURCE  C ODE 
Task  PEOI'EST  and  scheduled  report  GE  vE  >-  A  T  j 
remritfs  and  reformats  data  in  a  Fiir 
shifts  data  mthin  a  record 
StlPTS  a  file  IK  ascending  order 

PRODUCES  A  DIRECTORY  OF  a  BACKUP  TAPE 
COPIES  FILES 

pAGE*OR IENTEP  TEXT  EDITOR 

sets  he*LE TT. Packard  TfrhjnaL  CHARACTERISTICS 
LIST  A  FILE  to  The  USE®  TERMINAL 
COPIES  A  FILT  TO  A*  IB*  SELECT1C  TYPEcRITfB 
COPIES  A  FILE  TO  A  hE»LETT. PACKARD  T£B“I«AL 
CASSETTE 


Ay  AND  TIM£ 

S  A  FILE  FOR  CHARACTER  STRING 
BUFFER  FOR  SPECIFIED  DATA 
ES  A  FORMATTED  LISTING 


are  CONTAINED  IN  the  FORTRAN  pun-TI“E  LIBRARY* 


SCANS  FDR  Disc  FILE  name 

exit  routine  FOR  subprogram  USING  ,EnTFXp 
FXIT  routine  for  Subprogram  using  .ENTvap 
fntry  poutine  for  a  fixed  parameter  subprogram 
fntrx  routine  for  available  parameter  subprogram 

SCANS  A  BUFFEP  FOR  SPECIFIED  D*Ta  {RE-ENTRanT) 
PROVIDES  INTERFACE  mITm  SYSTEM  SERVICE  CALL 
7  (SVC  7) 

SCANS  A  BUFFER  FOR  A  SPECIFIED  CHARACTER  STRING 
Transfers  CHARACTERS  from  one  puffer  TO  another 


INTERPATA  S/J? 
SPECIAL  UTILITY  50FTMARE 


AGERpi 

EST 

$UP- 

MAIT  SOURCE 

ci  n*he  plier 

RES  LINES 

DESCRIPTION 

assembly  IH  1 

IH  3299 1 

AGERO  ASSEMBLER 

total  i  !  .  329®, 
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PREDICTIVE  SOFTWARE  COST  MOOEL 


CONTINUATION  SHEET 


DATE:  28  Se 


U-PJ 


EST 


ci 

sup¬ 

plier 

*  A  I  T 
RP$ 

SOURCE 

LINES 

DESCRIPTION 

asmpi 

;  ih  i 

Ih  ! 

6115! 

6-PI  ASSEMPLER 

BPO°m 

.  Th  . 

IH 

1  65. 

CONVERTS  A  FILE  F0»  TRANSMISSION  TO  0.P1 

QWQQv* 

.  Ih  . 

IH 

1°1 . 

CONVERTS  A  FILE  AFTER  TRANSMISSION  FROM  6-PI 

1LINK 

.  IH  . 

IH 

2R  J, 

LINK  FROM  INTERDATA  TO  «-PI 

total 

•  • 

•  « 

• 

• 

• 

6766. 

MCS  (“ICROPPDCESSOR  DATA 

5VSTEHS) ! 

EST 

sup- 

HA  I WT 

SOURCE 

cr  ’<A"E 

PLIES 

RFS 

LINES 

description 

plmpo 

f  • 

•  IH  . 

• 

IH 

zopb! 

Intel  popo  crdss-assehblep 

M  L  I  w  K 

•  IH  „ 

IH  . 

636. 

LINK  F POP  TnTERDATA  TO  MRS 

total 

•  • 

•  • 

• 

• 

2525 

FLCL  (FLIGHT  LINE  COMPUTER  LOAOERIl 

EST 

SUP- 

«AINT 

SOURCE 

CI  na-E 

PLIER 

RES 

LINFS 

DESCRIPTION 

FFORh 

■  • 
•  IH  . 

• 

1  H 

27o| 

converts  files  f0r  transmission  to  flcl 

FLI-ik 

.  ip  . 

I H 

626. 

link  BETNEFN  INTEROATa  and  flcl 

total 

•  • 

•  « 

• 

f 

6q6 , 

PLOTTER  (TEKTRONIX) 


EST 

SUP-  MATT  SOURCE 

Cl  ^A«E  PLIE»  RES  LINES  DESCRIPTION 


PLOT  10 
LIP 

t 

• 

f 

TEA 

!  TER. 

.  IH 

• 

5795! 

ROUTINES  USED  TO 

CONTROL  THE  PLOTTER 

PLOTTER 

• 

TH 

.  IH 

959. 

general  user  plot 

Gf NERATIOR 

total 

• 

• 

6756! 

20 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


PATE:  28  Sen 


INTERDATA  B/32 
SYSTEM  SOFTWARE 


CI  Na“£ 

$UP»  ►aikt 

ME°  RES 

EST 

SOURCE 

LINES 

• 

a 

BACKUP 

• 

INT  .INT/IW, 

aTM  . 

oseriT 

• 

INT  .INT/IH, 

2038. 

BOCTPN£W 

• 

1M  .INT/im, 

a»2. 

CAL 

• 

INT  .INT/IH, 

0667. 

calmacro 

a 

JNT  .INT/IH, 

3870, 

cuplb 

a 

INT  .INT/JM. 

26. 

a 

•  a 

• 

CUPMT 

a 

INT  .JNT/IH, 

6611. 

a 

•  a 

a 

discdump 

• 

INT  , INT , JH, 

2621. 

DISCHECK 

a 

INT  .INT.IH, 

3076. 

D  T  Sr INT 

• 

INT  ,INT,JH. 

1067. 

riisw.ou 

a 

INT  .INT.IH. 

176. 

D'JMPr  t  nT 

a 

INT  .INT 

2035. 

E01TJ? 

a 

i-.t  .I'U/r  . 

525. 

FORTRAN 

a 

INT  .INT 

u/S  . 

HASP 

a 

INT  .INT/ih, 

6106. 

IFTRaN 

a 

GEN'/.GR/Im  . 

ioia. 

a 

PES  . 

a 

INITSPlC 

a 

INT  .INT/ih. 

166. 

LIBLOR 

a 

INT  .INT/ih. 

2676, 

KTk 

a 

INT  .INT/IH, 

8263. 

OSCOpv 

a 

INT  , I N  T / 1 N , 

1007. 

purge 

a 

IM  ,IH 

1  o7  , 

SPOOlFP 

a 

IM  .IM 

1653. 

SPCUPPT 

a 

INT  .INT/IH, 

2281  . 

TE  T  32 

a 

INT  .INT/IH, 

563B , 

TUT 

a 

INT  ,1# IT/IN, 

061  . 

wc  S 

a 

INT  .INT 

3633, 

OSAIDS 

a 

INT  .INT 

6067. 

copies  disc  pack  contents  to  and  fro*  mag  tape 
system  text  editor 

GENERATES  A  punch  tape  wITh  bootstrap  LOaDF* 
ASSEMBLY  LANGUAGE  ASSEMBLER 
ASSEMBLY  LANGUAGE  macro  PROCESSOR 
OBJECT. LEVEL  SYSTEM  generator  EOR  the  J6-6IT 
PROCESSOR 

OBJECT. level  SYSTEM  GENERATOR  for  The  32-MP 
PROCESSOR 

OUMPS  THE  CONTENTS  OF  A  CISC  BACK  IN  he* 

CHECKS  CISC  PACK  INTEGRITY 
INITIALISES  DISC  PACKS 
modifies  DISC  Rack  contents 

Panic  dump  (FOR  AFTER  SYSTEM  CRASHES) 

SYSTEM  TEXT  EDITOR 
FORTRAN  LANGUAGE  COMPILER 
allows  REMOTE  JOB  Entry 

INTERPRETER  OF  STRUCTURED  PROGRAMMING  uf 

eortran 

INITIATES  the  spool  QUEUE 

BUILP5  and  EDITS  LIBPARIES 

MULTI. TERMINAL  MONITOR 

SYSTFM  COPY  ROUTINE 

ELIMINATES  OLD  files  from  a  Disc  Pack 

allows  USER  CONTROLLED  INPUT  TP  The  spool  OUEUE 

CREATES  AND  MAINTAINS  SOURCE  FILES 

0S32  TASK  ESTASLISMEP 

task  file  patch  routine 

WRITABLE  control  STORE  support  software 

assembly  LEVEL  DEBUGGING  TOOL 


*ww«ThE  FOLLOWING  ARE  SYSTEM  LIBRARIES#  ‘NO  CONTAIN  TOO  MANY  SYSTEM  ROUnTINES 
TO  an“E  and  PFSC°IBE  SEPARATELY**##*** 


DRIVER 

SYS 


■  JI»T  .INT/ih,  27063,  PROVJOES  *LL  SYSTEM  pPIVER  ROUTINES 
,  INT  .INT/ih,  36137,  PROVIDES  ALL  SYSTEM  MODULE  ROUTINES 


*.«»*ThE  Two  PRECEDING  LIBRARIES  CREATE  the  operating  system 

FORTRAN  ,  jnT  .JfT/IH,  2317R,  PRPVIOES  SUPPORT  FOR  The  FORTRAN  VI  LANGUAGE 
RUN-TIME  ....  wITh  MATHEMATICAL  FUNCTIONS,  I/O  FACILITIES, 
.  .  ,  .  ANO  REAL  time  INTERFACES. 


206 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  28  Sept 


TU1»L  .  .  .IDnBRT. 


INTEPD/Ti 

[TP  ( OPER  AT  I QNAL  FLIGHT  POOGRAm) 
"TILITY  SOFTWARE 


Cl  N'amE 


Sup-  MAT*:! 
PL1EP  FES 


EST 

SOURCE 

LINES 


DESCRIPTION 


ADDNO" 

.  IH 

.IH 

•  « 

.  2375. 

CREATES  And  ADDEnmii*  tape 

ChkmaS 

.  IH 

.IH 

.  m. 

UPDATES  "BAS*  VALUE  in  KEY-INS  FILE 

El MOpP 

.  IH 

.IH 

.  220. 

EL I*T  NaTF  S  UNUSED  OFP  DOCU“ENTATION  FILES 

.  IH 

.IH 

■ 

GENERATES  ofp  DOCUMENTATION  Files 

I nt  ofp 

.  IH 

.I1" 

.  115. 

initializes  dfp  documentation  files 

kf  Ile 

.  IH 

.IN 

.  15. 

f.nter  he*  address  in  »  k*  dfp  documentation 

• 

*  • 

file 

LSTPfp 

.  IH 

.I*" 

.  1211. 

LISTS  ALL  dfp  documentation  FILES  ASSOCIATES 

wJTM  A  change  cycle 

OFPOaTa 

.  IH 

.1” 

.  2712. 

READS  AND  punches  OFP  punch  Tapes 

refile 

.  IH 

.  IH 

•  64. 

LIST  ERRORS  AND  HAPNINGS  FRO"  OFP  ABSOLUTE 

• 

•  • 

LISTING  file 

the  following  ofp  ci's  are  contained  in  the  ofp  library 


AR7«IN 

.  IH 

.IH 

.  3P7 

AR7NCD 

• 

.  IH 

^  I  M 

3*8 

BINHEx 

!  IH 

!ih 

!  207 

B I NOc  7 

.  IH 

.IH 

.  212 

BINN'CU 

.  IH 

.IH 

.  308 

B I NPpT 

.  IH 

.IH 

.  2R5 

HfXpiN 

•  IH 

.IH 

.  230 

HEXPPT 

•  IH 

.IH 

,  316 

JULBJN 

.  IH 

.  IH 

.  231 

JULIAN 

.  IH 

.IH 

.  2UU 

OCTbjn 

i  IH 

.IH 

.  207 

PPTTIT 

.  IH 

.  IH 

.  307 

RPTbjn 

• 

.  IH 

IlH 

!  308 

PPTNfU 

.  IH 

.IH 

.  303 

SORT 

•  IH 

.IH 

.  1283 

TOTAL 

• 

. 

• 

• 

.*  13286 

Converts  an  art  format  file  f0r  the  r.pj 
TO  BINARY  IN  CHAC  format 
CPMVERTS  an  art  format  eke  For  the  NCU  to 
to  BINARY  in  CMAC  format 
CONVERTS  LCH*  1R  bits  FROM  BINARY  TO  Hf x 
CONVERTS  LOH  1?  BITS  FROM  BINaRY  TO  OCTAL 
PRODUCES  NCU  PUNCH  TAPE 
PRODUCES  C“AC  PUNCH  TAPE  FOR  THE  A. PI 
CONVERTTS  THD  HE*  WORDS  TO  one  BINARY  WORD 

punches  <i  frames  of  tape  in  a-pi  format 
returns  date  ANO  time  IN  binary 
RETURNS  date  and  TIMF  in  ASCII 
CONVERTS  T*o  OCTAL  WORDS  TO  BINARY 
PUNCHES  man. Readable  punch  tape  leader  and 
TRAILER 

READS  A  #»PI  PUNCH  TAPE 
REAOS  A  NCU  PUNCH  TAPE 
UNIVERSAL  SORT  ROUTINE 


JNTERDATA 
DATA  REDUCTION 


6. 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  28  Sept  1979 


CI  name 

SUP¬ 

PLIER 

HAJNT 

R€$ 

E  ST 

SOURCE 

LINES 

ACILPL 

I" 

• 

.1" 

238 

AC1LIST 

I" 

.IN 

.  021 

AC1REA0 

I" 

•  In 

.  155 

CLFPRM 

!« 

• 

.IN 

.  1919 

ENGLST 

!M 

.  I" 

.  SSOB 

GENFjle 

!H 

.1“ 

.  1030 

Label 

I** 

.IH 

.  25 1 

MERGE 

IN 

•  IH 

.  25*5 

PDFDtiMp 

I" 

‘.IM 

'  220 

$-OUmP 

I" 

.!»* 

.  2609 

SmEDiT 

I" 

,1m 

.  T77T 

SmfIlE 

I« 

•  I" 

*  12191 

S“EORm 

IM 

.IH 

.  1359 

SmlIST 

I" 

,  lH 

9982 

smmerg 

I" 

.In 

.  1527 

DESCRIPTION 


AOPVcS 

ASCHE* 

Afi£Np 

ASCINT 

ATI«e 

ecDPjf.' 

fll 

BITS 

BTImE 

BITS 

coate 

cf fcBSA 
CP686A 
CPfeOfi* 

CPpBiY 

CPfcPfcZ 

DUMP 

FTda 
FT  10 

FTJWJT 
INTEB* 
INTEflB 
I N  THX  A 
IWTWXP 
KPMP4R 

LSTm$G 

MVCHP 


CREATES  IBM  STANDARD  tape  labels 
LISTS  AC  1  FORMAT  DATA  SETS 

beads  ac i  format  op  ibm'  v  format  magnetic 

TAPE 

REFORMATS  Tspj  OR  aLast  Pave  FLIGHT  Test 
data  tape 

LISTS  the  REFERENCE  data  file 
CREATES  CARD  image  Input  for  SMFILE 
CREATES  IBM  standard  TAPE  LABELS 
MERGES  FLIGHT  TEST  OATA  AND  GROUND-B*SED 
INSTRUMENTED  range  data  “ 

lists  permanent  data  files 
LISTS  PERMANENT  data  FILES 
FORMATS  AND  Tags  OaTa  from  a  temporary  oaTa 
FILE  TO  A  PERMANENT  daTa  FILE 
BUILDS  A  REFERENCE  OATA  FILE 
creates  an  ac i  Data  base  fro**  a  pehkanfnt 
data  file 

PROVIDES  PRINTED  REPORTS  of  FLIGHT  TEST  t-ATA 
MERGES  Tmo  Permanent  DAU  FILES 


THE  FOLLOWING  O.R.  Cl'S  ARE  CONTAINED  IN  THE  GDUSFR  L1BPAR» 


,  COMBINFS  DOUBLE  PRECISION  PARITY,  VALIDITY. 

,  CONTROL,  AND  SPARE  BITS 
.  CONVFRTS  ASCII  HFX 
,  ABNORMAL  ENOS  dump 

,  CONVERTS  FRO"  ASCII  TO  BINARY  INTEGER 
,  PROVIDES  TIME  OF  DAY 
.  CONVERTS  BCO  TO  BINARY 
,  EXTRACTS  BITS  FROM  a  HALFWORD 
,  EXTRACTS  BITS  FROM  a  FULL  WORD 
,  PROVIDES  TIME  OF  DAT 
,  EXTRACTS  bits  from  a  DOUBLE  WORD 
,  provides  calendar  data 

,  READS  FLIGHT  TEST  TAPE  ID  RECORDS 

,  moves  DATA  BETWEEN  buffers 
CONVERTS  TIME  WORDS  FROM  INTEGER  TO  FLOATING 
POINT 

CONVERTS  TIME  WORDS  FROM  FLOATING  POINT  TO 
INTEGER 

READS  flight  TEST  DATA 

REGISTER  AND  CORE  DUMP 

READS  ONE  FRAME  OF  FUG"  TEST  DATA 

DEFINES  CHANNEL  CODES  AND  READS  ID  INFORMATION 

READS  INPUT  values  and  INITIALIZES  arrays 

converts  integer  To  ASCII 

CONVERTS  INTEGER  to  ASCII 

CONVERTS  INTEGER  to  HEX 

converts  integfr  to  hex 

LOGICAL  compare  between  Two  CHARACTER  STRINGS 
LISTS  MESSAGE  TO  THE  OPERATOR  CONSOLE 
"DYE  CHARACTER  RFPEAT  ROUTINE 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 
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ROUMp 

IN 

.IN 

.  R5, 

DUMPS  REGISTER  CONTENTS 

BEAD _ 

IH  . 

-..IK  . 

— .  -35. 

NON-BUFFERED.  UNFORMATTED  .BINARY 

READ 

sbyte 

IN 

.IN 

.  ST, 

SNAPS  BYTES  IN  POP  WORDS 

status 

IN 

.IN 

.  «. 

OBTAINS  JOS  STATUS  INFORMATION 

tslsrt 

IN 

.IN 

.  116. 

bubble  sort 

TRANSL 

IN 

.IN 

.  T2« 

CONVERTS  FROM  EBCDIC  TO  ASCII  AND  VISA-VERSA 

write 

• 

IN 

.IN 

.  35. 

NON.fUFFERED  UNFORMATTED  BINARY 

WRITE 

:i  n*me 

SUP¬ 

PLIER 

PAINT 

RES 

EST 

SOURCE 

LINES 

ACLQmP  _ . 

H 

-IN/H... 

100 

acutil 

M 

.IH/M 

.  22«0 

atab 

M 

.IM/H 

.  280 

N 

,IM/H 

SASLIR  . 

M 

.IN/H 

.  4060 

;naOFP  , 

M 

,  IN/M 

,  120 

;haon  , 

IN 

.IN 

100 

:obol  \ 

H 

|m/im 

!  1180 

JaT.POOL  . 

w 

.h/jn 

,  l«oo 

)I5kcmeck  , 

M 

,m/In 

,  BO 

»ORTr*n 

H 

.  .  M  /  I  M  . 

17280 

JENCLIB 

H 

.M/IM 

.  300 

IFTR*n  „ 

GEN/.GP/IM 

.  1918 

«ES 

ISUTjl 

H 

.m/im 

,  A«0 

JOBCNTRL  1 

H 

J.M/IH  _ 

L  20350 

.FED  I  TOR  . 

N. 

.H/IH 

,  I860 

xSUTjl 

H 

.M/IM 

.  1*1 

}  COgOL  , 

M. 

.M/IM 

,  ASO 

»RWF  , 

M 

.M/IM 

,  3S0 

«patCm  I 

M 

!h/IH  )  N/A 

IAMI*«  , 

IN 

.IN 

,  100 

lAUTeST  » 

IN 

.IN 

.  10 

f APESORT  * 

H 

!m/im 

;  N/A 

IEST 

IM 

.IN 

.  I* 

ILABEL  .  M  .H/IM 

1620. 

V 1 ACP Y| V  , 

H 

.H/IH 

.  120 

Y|ACSM|V  , 

H 

.M/IM 

.  260 

DESCRIPTION 


unknown  _  _  _  _ _  _ 

ACCOUNTING  UTILITY 

Real  TINE  PROGRAM  TO  ACCUMULATE  NUMBER  op 
SECTORS  USED  ST  E ACM  USER 
BASIC  LIBRARY 

INITIATES  PROGRAM  V»C«OPlv  TO  PUT  PRINTER 

...OPE.  LINE.  ....  _ _ _  .  .  .  - 

INITIATES  PROGRAM  V|C«0N|V  TO  PUT  PRINTER 
ON  LINE 

COBOL  COMPILER 

PROCESSES  DATA  AREAS  USED  S'  PORTRaN  COMPILER 
VERIPIES  INTERNAL  LOGIC  INTEGRITY  OP  Tme  DISC 
PORTRAN  COMPILER  _  ....  _ 


0,  INOE*E0  SEQUENTIAL  UTILITY  primarily  used  por 
.  COBOL 

D, -INTERACTIVE  USER  . INTERFACE  To  VULCAN. ...  ..  .  . 
0.  LIBRARY  PILE  EDITOR 
I,  SORT/MERGE  UTILITY 
0,  ANCILLARY  PROGRAM  USED  BY  .COBOL 
0,  PROVIDES  OCTAL  or  ASCII  DUMP  OP  SELECTED 
.  RECORDS  OF  A  FILE 

HARRIS  SUPPLIED  SYSTEM  PATCH  _ _ _  _ 

5 .  CHECKS  A  DISC  FOR  UNUSED  AMN0  SHaREO  SECTORS 
0.  EXERCISES  SCIENTIFIC  ARITHMETIC  UNIT  (SaU)  AND 
,  ABORTS  ON  ERROR 
,  SORTS  RECOROS  ON  TAPES 
k,  EXERCISES  MULTIPLLICATION  FUNCTION  OP  SAU 

la  TAPE  LABEL  PROGRAM  .  _ _ 

9,  ACCOUNTING  RECORD  COPY  PROGRAM 
0.  ANCILLARY  ACCOUNTING  UTILITY 
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CONTINUATION  SHEET _  DATE:  28  Sept  1979 


V«ASCT|V  ,  H 

,H/IH 

200, 

ACCOUNTING  SECTOR  REAO/HRITE  SERVICE 

-iiAJLl*  - »  H 

-  120*- 

-ANCILLARY.  ACCOUNTING  UTILITY 

V 1 BFM2 1 V  ,  N 

.H/IH 

160. 

BLOCKED  DISC  AREA  HANDLER /EXTENSION 

<|BLAH|V  ..  H 

,N/IM 

1200. 

BLOCKED  DISC  AREA  HANDLER 

/iCAjFtv  ,  h 

120. 

DISCONNECTS  LINE  PRINTER  AND  CARO  READER 

Y|C40N|V 

.IH 

.  100. 

CONNECTS  LINE  PRINTER  AND  CARD  READER 

(iCBaSjV  ,  H 

.H/IH 

100. 

BINARY  CODED  DECIMAL  TO  ASCII  CONVERSION 

.  VlCEAS(V  *_  M 

.H/IH 

_  _260-  22CD1C  TO  ASCII  CONVERSION  _  _ 

/|CP0N|V  .  M 

.H/IH 

S00, 

CARD  PUNCH  HANDLER 

(lCP0S»V  .,  H 

.H/IH 

600. 

CONTROL  ROINT  QUEUE  SHITCHER  RROGRAH 

/|C»0H|V  .  M 

.H/IH 

S00. 

CARD  READER  HANDLER 

/|CRPH|V  .  w 

.H/IH 

1520. 

CARD  PUNCH  HANDLER 

/|C»TH»V  ,  M 

.H/IH 

1B60, 

HARRIS  CRT  HANDLER 

_ _ h._ 

— .K/JM_ 

-.240,. 

.POST  MORTEM.  DUMP.  GENERATOR _  __  ...  _  i 

/ 1 OUMprR | V  H 

,H/IH 

000. 

REAL  tine  PORTION  OP  DUMP  PROGRAM 

<l£KT3|V  IN 

.IH 

80. 

'iCENSyV  ,  h 

.H/IH 

I  BOO  , 

SYSTEM  GENERATION  MONITOR  program 

.  /»HC*D|»  ...  H 

.H/IH 

340. 

line  PRINTER  HEADER  RAGE  GENERATOR 

MIDaC|V  ,  H 

.H/IH 

• 

2200, 

DIRECT  MEMORY  ACCESS  CONTROL  PROCESSOR  SUPPORT 

MODULE  .......  ...  _  ... 

/ 1  I**C*  1  V  .  H 

.H/IH 

80. 

INTERRUPT  EKECUTIVE  SERVICE 

'|IT8R|V  ,  h 

.H/IH 

320. 

INTERACTIVE  TERMINAL  SPOOLER  PROGRAM 

'|L»0M|V  .  M 

.H/IH 

TB0  , 

universal  line  printer  HANDLER 

/«UI*1H|V  .  H 

.H/IH 

1060. 

UNIVERSAL  LINE  PRINTER  HANDLER 

ML^ZMjV  .  HK 

.H/IH 

980. 

VERSATEC  LINE  PRINTER  HANDLER 

_UiBlN|V_._N 

— .H/W 

..  84(U__ASYnCHR0N0US  LImE .  PRINTER  HANDLER  - . ______ 

<|LPG0|V  IH 

.IH 

420. 

HOOIPIED  LINE  PRINTER  MANOLER  FOR  GO  header 

PAGE 

'»MEMD|V  .  IH 

.IH 

1200. 

CHECKS  OUT  C  PROCESSOR 

,IMESG|V  ,  H 

,H/IH 

680, 

MESSAGE  (SENO  RECEIVE)  SERVICE 

'»0LAY»V  .  H 

.H/IH 

oeo. 

OVERLAY  SERVICE 

.  ‘lOpC0«V  .  H _ .H/IH 

_660. 

OPERATOR  communications  command  interpreter 

'lOPcnv  .  H 

.H/IH 

600. 

OPERATOR  COMMUNICATION  SEGMENTS  •  EACH 

• 

PROCESSES  ONE  OR  MORE  0PC0M  commands 

'lOPcZlV  ,  H 

.H/IH 

600, 

•  •  ft 

*|0»CJ|V  .  H 

.H/IH 

900. 

■  «  ■ 

<|0Pc«|V  ,  H 

.H/IH 

620. 

■  ft  • 

•_»0PC5|V  .  H 

_,H/IH 

900. 

ft  •  • 

'lOPCBlV  ,  H 

.H/IH 

620. 

ft  ft  IB 

'|0PC7|V  .  H 

.H/IH 

340. 

ft  ft  ft 

■jOPCBfV  ,  H 

.H/IH 

460, 

ft  ft  ft 

•|OPC*|V  .  H 

.H/IH 

720. 

ft  ft  ft 

lOPCAlV  ,  H 

.H/IH 

480, 

ft  ft  ft 

'lOPCBfV  .  H 

-.h/jh 

_  .720, 

ft  ft  ft 

lOPcClV  .  H 

.H/IH 

780, 

ft  ft  ft 

«0PC0|V  ,  H 

.H/IH 

320. 

ft  ft  ft 

iOPcmv  ,  M 

.H/IH 

3V0, 

ft  ft  « 

•OPcZjV  ,  H 

.H/IH 

140, 

ft  ft  ft 

|P.PH|V  ,  IH 

.IH 

1454, 

HANDLER  POR  HARRIS  end  OF  INTEROATA. HARRIS  LINK 

iPICOiV  .  IH 

—.IH 

200.. 

non.resident  manoler  that  puts  out  go  header  _ 

|PTpH|V  ,  H 

.H/IH 

700, 

PAPER  tape  punch  manoler 

'f  PTBH|  V  ,  H 

.H/IH 

360  , 

paper  tape  READER  handler 

»REhh,v  ,  H 

.H/IH 

460, 

DISC  DIRECTORY  rehash  SERVICE 

|R»C2|V  .  H 

.H/IH 

460, 

RESOURCE  ALLOCATION  SERVICE  -  PART  2 

|R3CX|V  ,  H 

.H/IH 

520. 

RESOURCE  DEALLOCATION  SERVICE 

fRSRCjV  .  H 

.H/IH 

_J  120, 

RESOURCE  ALLOCATION  SERVICE  ..  .  _  _  _ 

,ftrex,v  ,  h 

,H/!H 

80. 

REAL  TIME  E*ECUTIVE  PROGRAM  (USED  FOR 

.  « 

• 

• 

• 

TIMER  SCHEDULING) 

_ _ _ 
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|RT ph,v  ,  H  , h/jm  ,  600.  REAL  TIME  PERIPHERAL  HANDLE* 

l SCAN i y _ ,._.B _ ..H/IM  _  ._  1220.  FOR-AT  SCANNER  SERY1CE1 

I SERV | V  ,  M  ,M/JH  ,  laoo,  BACKGROUND  SERVICES 


|S»V2|V  . 

H 

.H/IH 

.  3«0. 

BACKGROUND  SERVICES 

«SY25|V  . 

M 

.H/IM 

.  6*0. 

SYSTEM  INITIALIZATION  PHASES 

ISVIUV  . 

H 

.H/IH 

.  too* 

SYSTEM  INITIALIZATION  PHASES 

|SYI2,v  . 

H 

.H/IH 

.  920. 

SYSTEM  INITIALIZATION  phases 

_isr  is 

H._ 

.  .h/ih 

.. _ 10 00 .—SYS TEH  INITIALIZATION  PHASES  -  .  .  _ 

JSYJAIV  , 

H 

.M/IM 

.  u«e. 

system  initialization  phases 

»TEN2|V  . 

H 

.  H  /  I H 

.  390. 

PHASE  2  OF  Y t  TENS  1 V 

1  TENS i Y  , 

H 

.H/IH 

.  800. 

5  SECONO  SYSTEH  CHECK  PROGRAM 

itlhjiv  . 

H 

.H/IH 

.  I960. 

TAPE  LABELING  SERVICE 

«TLH?|V  , 

H 

.  H/ 1 M 

.  2380 , 

TAPE  LABELING  SERVICE 

_jTLSSiVL.^_ 

M  _ 

TBO*. 

TAPE.  LABELING  SERVICE  _  .  -  .. 

|T0a0|V  , 

H 

,H/|H 

.  1000. 

REAL  time  SERVICES 

iTRaPiv  . 

H 

.H/IH 

.  620. 

VULCAN  EXECUTIVE  TRAP  SERVICE  ROUTINE 

|TTYH|V  , 

M 

.H/IH 

.  IT60. 

TELETYPE  handler 

lUPRGiV  , 

H 

.H/IH 

.  200. 

USER  NUMBER  disc  AREA  PURGE  PROGRAM 

iupus iv  . 

M 

.H/IH 

.  180. 

UPDATE  USER  ACCOUNTING  SERVICE 

I.ySE»jY_... 

N 

_.h/jh._ 

.. — 380.. 

USER  NU-BER .  LOOK  UP  SERVICE  ...... 

•USPClY  . 

H 

.H/Jh 

.  200. 

DISC  SPACE  DEALLOCATION  SERVICE 

ASSE- 

H 

.H/IM 

.  9980. 

ASSEMBLY  LANGUAGE  PROCESSOR 

BASIC  . 

N 

.H/IH 

.  9020 . 

BASIC  PROCESSOR 

ILCanoO  . 

IH 

.IH 

.  16990. 

DISC  COPY  OF  RESIDENT  VULCAN  THAT  IS  »l'T  INTO 
m£M0RY 

ULCaNIZ _ .  . 

IH 

- .  I M  . - 

200. 

CREATES  load  MODULES  .  ...  ........ 

■  ReF 

M 

.h/Ih 

.  2060. 

CROSS  REFERENCE  PROCESSOR 

IBERV 

M 

.H/IH 

.120800. 

HARRIS  SYSTEM  LIBRARY 

iCASSlV  . 

H 

.H/IH 

.  1620. 

CASSETTE  HtNOLER 

'ORP 

IH 

.IM 

.  >0. 

EXERCISES  exponentiation  function  in  $AU 

jETcjV 

IH 

.IH 

.  120. 

non-resident  HANDLER  for  obtaining  CONTENTS 

on  MEMORY  SYSTEM  id*  AND  OAT  OF  THE  meek 

t  UaqR i v  , 

IH 

.IH 

.  100. 

ABSOLUTE  DISC  READS  FOR  USER  ROUTINES 

«PHD 

TOTAL  ! 

M 

.H/IH 

• 

• 

.  1980. 

1292953! 

POST  hqrtEH  OUHP 

HARRIS  F/FB 
UTILITY  90FT«AR£ 


SUR-  HAINT  SOURCE 

:l  n*h£  «*UE»  RES  LINES  DESCRIPTION 


N 

.  I H  I H 

• 

103 

OHRurr 

IH  ,IM 

• 

5lV 

opttape 

IH  .IH 

• 

200 

-c 

IH  ,IM 

• 

60 

F 

IH  .  1 H 

• 

N/S 

FLHNgXAP 

IH  .  JH 

• 

260, 

• LHNgveR 

_ IH_»JH_ 

- «  ■  - 

_ 260 

n'TRy 

IH  ,IH 

• 

190 

tmTSnapj 

JH  ,JH 

• 

65, 

CONVERTS  NUHRER  TO/FROH  INTEGER,  OCTAL,  HEX, 

6..  ASCII  -AND  TaSCII  . ._  _ _  _ _ 

,  FLOATING  point  CALCULATOR 
.  COPIES  ONE  hag  Tape  to  another 
,  DISPLAYS  SELECTEO  LOCATIONS  OF  CORe 
,  DISPLAYS  MAPRING  INFORMATION  FOR  A  FILE 
,  ELIMINATES  FILES  IN  A  HAP  OUTPUT 
,  ELIMINATED  FILES  IN  A  VERIFY  OUTPUT.  .. 

.COPIES  DATA  FROM  HP  TAPE  CASSETTE  TO  DISC  FILE 
.  SPOOLS  SNAPSHOT  OF  CRT  SCREEN  TO  PRINTER 
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e-ncmo 

IH 

.IH 

14T,  GENERATES  Command  FILE  USEO  IN  »TC0PV2 

_ "J1C  Q _ 

_IH 

-.1* 

.  H/S 

.  GEHEPAL  PUPPOSE  COPY  ROUTINE  TO  SUPFOR  CAR-  . 

,  TRIOGE  ON  HP  TERMINAL 

<CE*C< 

IH 

.I- 

35a.  OUTPUTS  FORMATTED  LIST  of  FILES  ON  A  KCEPTaPE  I 

,  TO  THE  PRINTER  ANO  VERIFIES  THE  TAPE 

_r 

IH 

-IH 

66. 

COMPARES  2  FILES 

pcopy 

IH 

.IH 

240, 

COPIES  A  HAG  TAPE  IN  KEEP/FETCH  FORMAT  TO 

-  ANOTHER.  HAG  .TAPE  . . . 

N 

IH 

*  IH 

266, 

PROVIOES  A  LIST  OF  HHICH  LFN  •  S  APE  CURRENTLY 

ASSIGNEO  FROM  INTERACTIVE  TERMINAL 

•  E-use* 

h 

.H/IH 

80. 

CHANGES  QUALIFIER  AND/OR  USER  NUHeeR  OF  FILES 

- AKCMK 

IH 

-.IH 

-« 

•9. 

LISTS  FILES  -HICH  HAVE  NOT  BEEN  ACCESSED 

SINCE  THE  ENTERED  CUTOFF  DaT£ 

-  C.EADFILE_  _ 

,W_ 

-*IH  — 

_l480._BtA0S.FILE  INTO  AN. OUTPUT  FILE  ADDING  PAGE  . 

• 

• 

• 

NUHRE*S  and  CARRIAGE  CONTROL  FOR  SPOOLING 

• 

TO  THE  PRINTER 

‘FETCH 

• 

IH 

.IH 

220, 

CONSTRUCTS  A  JOB  STREAM  TO  FETCH  SELECTED 

FILES  FROM  A  TARE 

• N*Fj  T 

IH 

.IH 

•0, 

SNAPSHOTS  THE  CONTENTS  OF  A  TEC-425  SCREEN 

.-l£Q*r2__ 

IH 

_1132. 

■EAO/HRITt.  FROM.  DISC  TO  TaPE  AND  VISA-VERSA  . 

E 

IH 

.IH 

16257, 

TE*T  EDITOR 

MRU** 

IH 

.  I  H 

600, 

transfers  files  between  PROCESSORS  through 

• 

HIGH  SPEED  m|m0Rv 

PECFT 

IH 

.IH 

so. 

makes  DIRECT  BINARY  COPY  from  TAPE  TO  TAPE 

U*M«0 

IH 

.IH 

aO, 

ROTATES  PRINTER  OUTPUT  60  DEG, 

_ **EF _ 

IH 

_.LM_  . 

PRODUCES  VARIABLE  and  FILE  name  c«0S5  REFERENCE 

FROM  AN  ALPHABETIZED  LIST  OF  VARIABLES  ANO 

FILES 

-the 

IH 

.I- 

200, 

ALLOWS  USE*  TO  WRITE  TO  TAPE  CARTRIOGE  On 

• 

• 

• 

HP  TERMINAL 

£8 

• 

IH 

.  I  H 

• 

ISO. 

SEQUENCES  SOURCE  FILES 

. .......siHtie  • 

SIMULATION  LIS***T  CONTAINS  THE  FOLLOWING  SUBROUTINES!********* 

<  »NM| 

IM 

.  I H 

so. 

UNPACK  AREANAHE  FROM  TRUNCATED  ASCII  (4CPPJ 

TO  STANDARD  ASCII  C1CPW) 

M»J 

IH 

.IH 

SO. 

UNPACK  AREANAHE  prom  TRUNCATED  ASCII  («CPM) 

'■  ifi.  IT 

TO  STANDARD  ASCII  CJCPw) 

• 

IH 

.IH 

• 

ASSIGN  LPN  (NON  RESOURCABLE  PON«S  ONLY) 

IH 

.IH 

ss. 

ASSIGN  LPN  TO  CASSETTE  TAPE  ON  Tl  733 

lie* 

IH 

.IH 

76, 

ASSIGN  LFN  TO  DISC  AREA  (FILENAME  AND  OUALI- 

PIER  REQUIRED) 

*3.0** 

IH 

.IH 

ASSIGN  LFN  TO  DISC  AREA  (QUALIFIER  OEFaUlTS 

TO  SI6N-0N  QUALIFIER) 

STinf 

• 

IH 

.IH 

• 

56, 

ASSIGN  LPN  TO  ANOTHER  LFN  (FIRST  LFN  ASSIGNMENT 

• 

FOLLOWS  SECOND) 

aslinp 

IH 

.IH 

ASSIGN  LFN  TO  ANOTHER  LFN  (FIRST  LFN  ASSIGNHEN 

• 

DOES  NOT  FOLLOW  SECONO) 

>o*n 

IH 

.IH 

102. 

ALPHANUMERIC  SORT  on  an  array  in  standard 

* 

ASCII  (1CPN)  . ._ .  . 

Wtj 

IH 

.IH 

200, 

ALPHANUMERIC  SORT  ON  an  array  in  standard 

a 

ASCII  (JCPR) 

|T0*J 

IH 

.IH 

62. 

CONVERT  STANDARD  ASCII  (ICPw)  TO  STANDARD 

ASCII  (3CPM) 

lT0t« 

IH 

.IH 

TO, 

CONVERT  STANDARD  ASCII  (1CFW)  TO  TRUNCATED 

ASCII  C4CPN)  ....  . .  . 

|TBai 

Th" 

.IH 

• 

55, 

CONVERT  STANDARD  ASCII  (3CPW)  TO  STANOARO 

_ _ 

• 

• 

a 

• 

ASCII  CtCPp) 
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jtotr 

.  ix 

.IX 

«S, 

CONVERT  STANDARD  ASCII  (SCPw)  TO  TRUNCATEO 

ascii  (acrh;  . . 

-INHtX 

.  JH 

•  IX 

as! 

binary  to  he* 

INPPT 

.,  IX 

.IX 

200. 

binary  TO  BUNCH  barer  tare  .  . 

itomi 

.  1H 

.ix 

60. 

CONVERT  BINARY  U  WORD)  TO  HE*  (ASCII  ICR") 

(T0h3 

..  IH 

-IX 

bS. 

CONVERT  BINARY  (1  WORD)  TO  HEX  (ASCII  SCR") 

•.fn*w 

,  IN 

.ix 

bO, 

CHECK  LAN  ASSIGNMENT  STATUS  AND  OBTAIN  ASSIGN. 

..  KENT .  INFORMATION  _.  ..  .  . . 

.UCB* 

!  ix 

.ix 

«5. 

CONVERTS  BINARY  TO  ASCII 

.UIO 

IX 

-IX 

2bT  . 

LONG  PORN  OF  STANDARD  CALL  FOR  I/O  SERVICE 

)LUIO« 

.  IH 

.IX 

• 

CALL  FOR  I/O  SERVICE  TO  RETURN  CONTENTS  OF 

• 

A-REGISTER  AFTER  I/O 

1LUIOC 

.  ix 

.IX 

• 

CALL  FOR  I/O  SERVICE  FOR  CHARACTER  I/O 

-  -iLUlOE  ■■ 

_ . _ LM—---IH-. 

_ * 

CALL  FOR. I/O  SERVICE  TO  RETURN  CONTENTS  OF  .  _ 

• 

• 

E-REGISTE*  AFTER  I/O 

iLUJOS 

.  IX 

-IX 

SHORT  FORH  OF  STANDARD  CALL  FOR  I/O  SERVICE 

ILUIOK 

.  IH 

.IH 

• 

LONG  FOR"  OF  STANDARD  CALL  FOR  I/O  SERVICE 

-  -m 

• 

REQUESTING  A  "AIT  AFTERWARDS 

.ULFN 

.  IX 

.IX 

<2, 

CHEC*  LFN  ASSIGNMENT  STATUS 

_ ,UPJJN 

— __1H_ 

—IN 

_  35. 

CHECK  BDN  CHARACTERISTICS ....  . . . . 

/Hxai 

.  IX 

.IH 

Ob. 

CONVERT  HE*  (ASCII)  TO  BINARY  (J  WORD) 

/svjp 

.  IX 

.IH 

90. 

CONVERT  SYSTEM  0ATE/TI"E  IN  STIHE  FORMAT 

TO  ASCII  (MILITARY  POPMAT) 

»T£ 

.  IX 

.IX 

«2. 

OBTAIN  CURRENT  DATE  AND  TI"e  FRO"  SYSTEM 

(NF0l 

.  IX 

.IN 

205, 

OBTAIN  LIMITED  INFORMATION  ON  A  SPECIFIC 

t 

_ #  . 

DISC.  FILE _  ....  .  _ _ _ 

iinfos 

.  IH 

.ix 

obtain  moderate  amount  of  information  on  a 

• 

SPECIFIC  DISC  FILE 

)I“F03 

.  ix 

.IX 

• 

obtain  COMPLETE  information  on  a  specific 

« 

• 

DISC  FILE 

fT#§I 

.  IH 

.IX 

223. 

SCANS  ANO  CONVERTS  ASCII  pATE/TI"E  ("IL  OR 

JULIAN  FORMAT).  TO  BINARJT  ..  .  ... 

USE 

,  ix 

.IX 

75, 

clear  terminal  screen 

."NS 

.  IX 

.IX 

• 

7b. 

eliminate  a  SPECIFIC  DISC  file  (OUALIFIER  ANO 

• 

filename  REQUIRED) 

?LMNbS 

.  IX 

-IX 

ELIMINATE  a  specific  DISC  file  CSIGN.ON) 

QUALIFIER  ASSUMED) 

-ll^CH _ 

.  IH 

-IX. 

1  TO—. 

FINO  OCCURRENCE  OF  CHARACTER  IN  character 

• 

STRING  FROM  A  GIVEN  OFFSET 

(NOT* 

•  ix 

.IX 

22b. 

FIND  OCCURRENCE  OF  A  CHARACTER  STRING  IN  A 

LARGER  STRING 

1” 

,  IH 

.IH 

3b2. 

CONVERT  ASCII  REPRESENTATION  OF  A  FLOATING 

POINT  TO  INTERNAL  FLOATING  POINT  FOR"aT 

_ .spit 

—  — 1.x 

_ -  IH 

b«. 

set  a  SPECIFIED  bit  in  an  array 

ltu*T 

,  IH 

.IX 

1b3, 

FORMAT  LATITUDE/LONGTTUDE  INTO  ASCII 

1TLON 

•  lx 

.1“ 

FORMAT  LaTITUDE/LONGITURD  Into  ascii 

ISTCH 

,  ix 

.lx 

• 

<2. 

FINO  first  nonblank  character  in  a  character 

• 

• 

• 

STRING 

1C  AN 

■  IX 

.1“ 

2b5, 

CALL  TO  SYSTEM  FORMAT  SCANNER  SERVICE 

(NOA 

...  IH. 

—  IX. 

\b5. 

GENERATE  A  DISC  FJLE  WITH  ACCOUNT  ACCESS 

(SHORT  FORM) 

•nol 

.  IH 

.IX 

GENERATE  A  DISC  FILE  (LONG  FORM) 

JNOO 

•  IH 

.IX 

GENERATE  A  DISC  FILE  with  Owner  ACCESS  ONLY 

(SHORT  FORM) 

(NOP 

•  lx 

.IX 

GENERATE  A  DISC  FILE  "IT"  PU*LIC  ACCESS 

«  . 

-  - 

(SHORT  FOR") 

5X8IN 

.  ix 

.IX 

ISO, 

CONVERT  H£*  TO  BINARY 

:*in 

.  IH 

.IX 

• 

# 

INPUT  ANO  CONVERT  HE*  ASCII  (UP  TO  t  CHARACTERS 

i. 


213 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  28 


• 

• 

TO  BINARY  (1  WORD) 

'*»PT _ 

- _ IH _ -_I  H 

__ i6*U- 

DATA  IIN-HEXJ.  .TO  PUNCH  PAPER  TAPE 

10RT3 

IH 

.IH 

• 

96. 

HR*  SORT  ON  ASCII  REPRESENTATION  OP  HEX 

- 

• 

NUHBER8  JN  AN  ARRAT 

itOBI 

IH 

.IH 

• 

82. 

CONVERT  HEX  (ASCII  1CPN)  TO  BINARY  (1  *ORD) 

„U?Tx._  . 

IH 

.IH  ... 

*...  .. 

_  95. 

OBTAIN  PSQ6RAH  OPTIONS  P»0H  PROGRAM  OPTION 

• 

• 

• 

•  ORD  PROM  INITIALIZATION 

ILNrK 

.  .IH 

.IN. 

-ANOTHER  -ENTRY  .POINT  .FOP  FRSTCH- 

J  JLlAN 

IH 

.IH 

• 

115. 

CONVERT  RETURN  PROP  SYSTEM  STIMf  SERVICE  TO 

... 

4 

• 

JULIAN  POPM  OATE  AND  TIH£ 

»P«PI 

IH 

.IH 

• 

60. 

CONVERT  A  HARRIS  PLOATING  PONT  NUMBER  TO  API 

_  .. 

• 

A 

FIXED  POINT  NUMBER 

)«P*« 

IH 

.IH 

122. 

COMPARE  CHARACTER  STRINGS 

l?l£H 

. I  H_ 

— .  IH — 

_ 

— 1 91*_EIHO.tASI.^OHU.JlNAiMiRAtI£R8  1N._A  XHARAC.U* 

• 

• 

• 

STRING 

.  UTing 

.  IH 

.IH 

Hi. 

COPT  FILE  TO  PILE  KITH  PRINTER  SPACING 

JTNbk 

IH 

.IH 

ANOTHER  ENTRY  POINT  FOR  LASTCm 

*  JVC  SR 

IH 

.IH 

52. 

MOVE  CURSOR  ON  THE  TEKTRONIX  0014 

/Chr 

IH 

.IH 

too. 

HOVE  DATA  in  AN  ARRAY 

_;»Pa8n 

_ IN. 

_. IH  _  _ 

__75«_ 

SCAN. _OFP.  CNANGE/PROSLEH  DESCRIPTION . 

•JHRTO 

IH 

.IH 

• 

65. 

truncate  and  insert  ascii  Character  in  a 

-• 

* 

TRUNCATED  ASCII  ARRAY  C9CPm> 

JMOPT 

IH 

.IH 

99. 

OBTAIN  program  OPTIONS  AND  PARAMETERS  at 

« 

program  INITIALIZATION 

•TLOR 

IH 

.IH 

65. 

punch  paper  tape  leader 

_ •  T  TXT. _ 

- IH_ 

- »-IH - 

— 3S-. 

punch  paper  tpae  title.  _  . 

rcH*R 

IH 

.IH 

• 

197. 

CONVERT  ASCII  CHARACTER  TO  paper  tape  code 

IH 

-.IH 

86. 

rename  A  DISC  FILE  TO  A  new  Name  (QUALIFIER 

• 

• 

f 

AND  FILENAME  REQUIRED) 

«enams 

IH 

.IH 

« 

REHAME  a  OISC  FILE  TO  A  nem  na«E  (SIGN.ON) 

t 

• 

• 

QUALIFIER  ASSUMED) 

._i.ir.ER _ 

— ~i-E- 

_ .1  - _ 

. 

.1M.-ERTVP£  .  A  pj SC- PILE.  TO.  A-EE*  -TvpE-SPECIfIC*tion_ 

• 

• 

(LONG  FOR") 

IETyPS 

IH 

.1“ 

• 

t 

RETYPE  A  OISC  PILE  TO  *  NE*  TYPE  SPECIFICATION 

• 

• 

• 

(SNORT  FORM) 

•TRIM 

IH 

.IH 

199. 

»eao  paper  tpae  and  convert  to  binary 

»TH£X 

IH 

.IH 

• 

17«. 

READ  PAPER  tpae  and  convert  TO  HEX 

lose 

IH 

-,AIH- 

* - 

65.-RE80URSE  DISC  PACK 

rsoset 

IH 

.IH 

• 

• 

TEST  OISC  RESOURCE  REOUEST 

ISDSCM 

IH 

.IH 

A 

• 

SPECIFY  A  NAIT  UNTIL  RESOURCE  REQUEST  FOR  DISC 

• 

A 

« 

PACK  mas  BEEN  FULFILLED 

|mSm 

IH 

.IH 

• 

75. 

RESOURCE  HIGH  SPEED  MEMORY 

IShsmT 

IH 

.IH 

• 

• 

TEST  HIGH  SPEED  “EMORY  REQUEST 

_ ISHSHX 

„ _ |  M _ .  IH _ 

_ 

_ 4 

SPECIFY  A  MAIT  UNTIL  RESOUCt  REQUEST_POR.  _ 

• 

A 

t 

HIGH  SPEED  MEMORY  FULFILLED 

IflTt 

.  iM 

.IH 

• 

105. 

RESOURCE  mag  TAPE  (LONG  FORM) 

IS**TLT 

.  I H 

.IH 

• 

• 

test  mag  TAPe  RESOURCE  REQUEST  (LONG  FORM) 

IS>*Tl*i 

,  IH 

.IH 

• 

t 

SPECIFY  A  MAIT  UNTIL  RESOURCE  REQUEST  FOR 

• 

• 

• 

MAC  TAPE  has  BEEN  FULFILLED 

_1"TS 

.  IH 

..  I H _ 

.  86. 

RESOURCE  MAG  TAPE  (SNORT  FORM j 

IShjST 

.IH 

• 

• 

TEST  mag  TAPE  PESOURCE  REQUEST  (LONG  FORM) 

ISHTSP 

.  lH 

.IH 

• 

SPECIFY  A  MAIT  UNTIL  RESOURCE  REQUEST  FOR  MAG 

• 

• 

TAPE  MAS  BEEN  FULFILLED 

IPON 

.  IH 

.IH 

• 

86. 

RESOURCE  PON  (MUST  BE  RESOURCEABLE) 

ISPONT 

.  IH 

.IH 

• 

TEST  PDN  RESOURCE  REOUEST 

ISPO*'* 

«_  IH 

. 

SPECIFY  A  maIT  UNTIL  RESOURCE  REQUEST  FOR  PDN 

t 

• 

MAS  SEEN  FULFILLED 

•  JTSJT 

,  IH 

.iM 

m 

51. 

SET  "IT  IN  A  VECTOR  ARRAY 

)RT 

IH 

.IH 

00, 

8 INART  SORT  ON  AN  ARRAY  6V  ROW 

1Z_  _ 

-IH- 

-.IH 

62. 

SOUEEZE  BLOCKED  DISC  FILE  TO  MIN. 

RE3UIRFmENT 

iozub 

IH 

.IH 

SOUEEZE  AN  UNBLOCKED  DISC  FILE  TO 

MJNJPUH 

• 

• 

REBUIRE“ENTS 

itoai 

IH 

.IH 

63. 

CONVERT  TRUNCATED  ASCII  («PC“)  TO 

STANDARD 

• 

ASCII  (ICRw) 

iToas 

IH 

.IH 

87. 

CONVERT  TRUNCATED  ASCII  («CR«S  TO 

STANBABC 

-ASCII  I3CPMJ  . . . 

!TAL 

• 

• 

• 

» 

• 

• 

. .  . .  harri.s.  r/n _  „ 

RJE  (REMOTE  JOB  CONTROLS  SOFTWARE 


EST 


SuR- 

RLIEO 

-  HAJNT 
RES 

..  SOURCE 
LINES 

DESCRIPTION 

:/masr 

u 

!h/JH 

!  3220 1 

SPOOLER  FOR  RJE 

•.noer 

IH 

.Iw 

.  so. 

SCANS  RJE  FILE  and  WRITES  A  LIST  OF  CRITICAL 

-  _  - 

. - -  .  _• 

WARNING  OR  ERRORS 

~  'c;ij'E 

H 

,  H/  I H 

.  160, 

ORCO"  RJE  DRIVER 

IE 

N 

.M/I« 

.  1000. 

REHOTE  JOB  ENTRY  RPOCESSOR 

!E»T? 

IH 

.IH 

.  1300. 

WRITES  A  LIST  FORhaT  RJE  DATA  FILE  TO  "AO  TARE 

• 

•  ft 

FOR  LISTING  OR  HJCROFICHE 

'EGen 

* 

,  H  /  I H 

.  560. 

RaRaheTER  GENERATION  program  USED  in  CONFIGUR¬ 

_ _  _  _  _ 

_ 

^  _  # 

ING  the  IBM  SITES  INITIATED. BY  .RJE  _ 

:BERT  t  V 

H 

."/IH 

.  1*0, 

RJE  UTILITY 

.  !r-JEH|V 

M 

.  H/  1 M 

.  080, 

REHOTE  JOB  ENTRY  HANDLER 

...  !TAL 

• 

ft 

I  z«ic| 

HARRIS  F/FB 
RLOTTER  SOFTWARE 


EST 

BUR.  HAINT 

SOURCE 

:  file 

RUER  RES 

LINES 

DESCRIPTION 

iTRETwL _ I 

IH 

• 

•  ft 

...  *00. 

DATA  RETRIEVAL  PLOTTING  PROGRAM 

»rlot 

IH 

.IH 

.  160, 

PLOTS  WEAPON  SCORING  RELEASES  PRODUCED 

BY 

* 

•SCORE 

•LOT 

H 

,H/JH 

.  mo. 

VERSATEC  PLOTTER  ROUTINE 

.OTLIB 

H 

.H/IH 

.  RR60, 

VERSATFC  PLOTTER  LIBRA** 

1PL0T 

• 

IH 

.IH 

.  200. 

RERLOTS  OR  ELIMINATES  AREAS  CREATED  BY 
-•SCORE.  .KEEP  OPTION  _  ..... 

USING 

ft 

• 

•  • 

stal 


T5B0 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  28  Sept  1979 


PREDICTIVE  SOFTWARE  C08T  MODEL 


CONTINUATION  SHEET 


DATE:  28  Sept  1979 


TAG 

IH 

.IH 

1«0. 

_ ISAS. 

IH 

,  X.H _ 

.100, 

tSIO 

IH 

#  I H 

• 

700. 

-• 

;JNgT|V 

IH 

.IH 

• 

20. 

• 

iprls«v 

IH 

.IH 

• 

SO. 

1  SFRTf  V 

IH 

.IH 

400, 

iSASPlV 

IH 

.IH 

1400, 

• 

• 

• 

iTtflSl V 

IH. 

•  IH 

• 

48. 

• 

• 

• 

_ UAL- 

_ _ 

, _ 

21U, 

VARIABLES 

OUTPUT  TEST  INSTRUCTIONS  AN 
PROCESSOR  SNITCHES  TO  SA8 
INITIALIZES  AND  LOADS  DATA 

_ _ IN.  SAS  FROM  .£  PROCESSOR  —  . 

SA3  DIAGNOSTICS 
C  PROCESSOR  PROGRAM  THAT  00 
SIMULATOR 


HARRIS  F/FB 

_ _ _ II.huLATQR.-SOFTAlASE.-  .  _ _ 

EST 


!  na»e 

SUP¬ 

PLIED 

PAINT 

RES 

SOURCE 

LINES 

DESCRIPTION 

)RS 

■  Th  ' 

‘Ti'h  ~T  2l*T" 

GENERATES" ADDRESS  and  CROSS  REFERENCE  INPORMA— 

« 

• 

TION  FOR  MONITOR  COMMON  VARIABLES 

1LLIS  , 

I- 

.IH 

500. 

COMPUTES  BALLISTIC  CURVES 

<FR 

IH 

.IH 

200. 

LOADS  C  PROCESSOR 

tTRET 

IH 

.IH 

2SS0. 

RETRIEVES  SIMULATION  o*Ti 

_ !TRETOO _ , 

IH 

_.I  H . . 

_ ISO. 

QUICK  AND  DIRTV  data  RETRIEVAL  PROGRA* 

•SPEC 

IH 

.IH 

2240. 

sets  up  data  recording  file 

i  , 

IH 

.IH 

00. 

FUNCTION  -ORD  ASSEMBLER 

»Smlg  , 

IH 

.IH 

160, 

KEEP  ANO  fetch  .STMLOG  on  Tape 

JN I  TOR  , 

IH 

.IH 

140, 

MONITORS  MEMORY  LOCATIONS  AND  REPORTS  ANY 

• 

• 

changes  in  value 

„.AN  _ . 

IH 

.IH  . 

_  «320._ 

mission  Planning  program 

.ANUTIL  , 

IH 

.IH 

1840, 

PLANNING  FILE  UTILITY  PROGPaM 

•T.LOJS  . 

IH 

.IH 

20. 

RESIOENT  REAL  TIME  LOADER  FOR  *V|L0J5lV 

;or£ 

IH 

.IH 

500, 

COMPUTES  Tme  impact  point  OF  SIMULATION  VEAPON 

• 

• 

RELEASES 

:rial 

IH 

.I” 

100, 

MONITORS  SIMULATION  SERIAL  DATA  noRd  COUNTS 

..JTPaT  .. 

IH 

_.IH 

.  4  JQ. 

PUTS  A  knokn  YALUE  IN  MONITOR  COMMON 

/ 

IH 

.IH 

240, 

initiates  the  start  of  simulation 

•OATE  , 

IH 

.IH 

220, 

UPOATES  MONITOR  COMMON  DISC  FILES  USED  BY  ThE 

simulation  display  PROGRAMS 

1 ADRS | V  , 

IH 

.IH 

SO, 

COMPUTES  SEMI-CONDUCTOR  memory  LOCATION  OF 

MONITOR  COMMON  VARIABLES 

_ [CLORj  V _ 1 

IH  .IH 

.200, 

LOAOS  A  PROGRAM  IN  G  RROCESSOR  from  EIThER 

• 

• 

A  OP  B  PROCESSOR 

|IH70|V  , 

IH 

.IH 

200, 

INTERRUP  HANDLER  FOR  SIMULATOR  SOFTMARf  ON 

• 

A  PROCESSOR 

iLOJSiV  , 

IH 

.IH 

AO, 

SETS  UPHONITOR  SERVICE  6LU35  FOR  NON.RESIDENT 

• 

HANDLER  oViETCIV 

iSPCAiV  .  IH 

.I"  . 

500, 

SETS  UP  MONITOP  SERVICE  BLUJ6  ON  A  PROCESSOR 

ISPCBiV  , 

IH 

.IH 

TOO, 

SETS  UP  MONITOR  SERVICE  PLUJ6  ON  B  PROCESSOR 

[ENJNaP  , 

IH 

.IH 

<40. 

PROOECES  FORMATTED  LISTING  OF  ALL  SIMULATION 

PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


_ SORIVE 

IK  ,IH— 

100. 

TERO 

.  IN  ,1 H 

.  2«0, 

•  • 

•  ft 

UFUP 

.  IN  . 

.  TOO, 

.  .  - 

---A . . «  - 

•  ft 

'PLAN 

.  IN  . 

.  560, 

ft  « 

•  ft 

3TAL 

•  ft  « 

.  17706. 

DATE:  28  Sept  1979 


COMMANDS 

.RESCORES  NEAPON  D»0PS  B»  The  SlMULAT0R  .  .  . 

PROVIDES  A  LISTING  OR  SIMULATION  MONITOR 
COMMON  VARIABLES  IN  RILE 
UPDATES  CROJS-RERVERENCE  RILES  USED  BT 
•CMACRETV  AND  »Rm 

RESTRUCTURES  ■(. ANNINS  RILES  TO  THE  NCR  5  OFFSET 
-POINTS _ _  .  _  _ 


.  HARRIS -E/ZB— 
C“AC  SORTMARE 


$UP»  MAJNT 
PLIED  .»E5  — 


EST 

SOURCE 

..LINES  ... 


DESCRIPTION 


ataloo  . 

1H 

.IN 

ft 

360 

.OCRS 

IH 

.IN 

• 

20 

.OCKT 

IN 

.IN 

a 

too 

_ MACDIAG-,.- 

IN¬ 

-.IN 

4060 

racretv  , 

IN 

.IN 

a 

2R«U 

RACTEST  * 

IN 

.IN 

a 

«0*0 

RACTIME  , 

IN 

.IN 

• 

160 

JMPTP 

IN. 

.IN 

• 

100 

JRET  , 

IH 

.IN 

• 

134 

iCmaciv  . 

Th¬ 

_ _ 

.IN 

a 

• 

• 

’  IT  00 

3TaL  ' 

in 

• 

.IN 

• 

a 

11*74 

ROLL  SNAPSHOTS 
SETS  UP  “ONITOR 

WITH  cmac 


SUP- 

I  Name  PLIER 

MAIT 

PCS 

‘GERD  6660 
SVSTEM  SOFTWARE 

EST 

SOURCE 

LINES 

DESCRIPTION 

*9«0  O'sl  T I 

IN 

•  • 

.  N/S  . 

OPERATING 

SYSTEM 

POP 

11/40 

SYSTEM 

SORTMARE 

SUP- 

I  Name  PLIER 

MAIT 

PES 

EST 

SOURCE 

LINES 

DESCRIPTION 

ONlTOR 


N/S  ,  01  SR  OPERATING  SVSTEm  VOB-OB 


WP*«wn*.v 


■  i.iiiiYL«i  r---*-  -  "'~ 


PREDICTIVE  SOFTWARE  COST  MOOEL 


CONTINUATION  SHEET 


DATE:  28  Sept  1979 


I  p 

• 

DEC 

• 

PEC 

*/S 

FILE  UTILITY  PACKAGE  VP8-U2A 

NT 

• 

DEC 

• 

Pf  C 

N/A 

text  ecitor  voobA 

jwtdiv 

• 

OF  C 

• 

DEC 

N/S 

FORTRAN  COMPILER  VOOUA 

iC*0 

• 

"EC 

• 

PEC 

N/S 

ASSE“BLEB  VR0S-01A 

IBP 

• 

DEC 

• 

P£C 

N/S 

LIBRARIAN  VOORA 

I  N* 

• 

DEC 

• 

DEC 

N/S 

LINKER  VI1A01 

• 

"FC 

• 

PEC 

N/S 

DEBUGGING  PROGRAM 

I  IC0“ 

• 

DEC 

9 

DEC 

N/S 

FILE  COMPARE  PROGRAM  V02-08 

iur»-P 

• 

DEC 

• 

DEC 

N/4 

FILE  DUMP  UTILITY  VOOTA 

E*TP  Y 

• 

DEC 

• 

DEC 

N/S 

VERIFICATION  PROGRAM  V002-R 

XU'S 

• 

DEC 

9 

PEC 

N/S 

CORE  IMAGE  LIB  UPDATE  and  Save  vaou 

OIL  Is 

• 

DEC 

• 

PEC 

N/S 

UTILITY  TO  SAVE  DISK 

V$LOr> 

• 

DEC 

• 

DEC 

N/S 

system  loader  voosa 

rsiu*? 

• 

PEC 

• 

DEC 

r./S 

ABSOLUTE  LOADER  V006A 

pdp  ll/ao 

UTILITY  Snn«»»E 


I  ’  ame 

S!JP- 

pl  i  r.« 

"AIT 

Pf  S 

ESI 

SOURCE 

LINES 

tnlst 

9 

.  IM 

;  im 

N/S 

COPY 

.  IM 

.  Im 

.  105 

TO 

.  IM 

•  T  H 

.  226 

ABELS 

.  I  M 

.  Im 

.  1 1 

DT 

.  IM 

,  I" 

.  a?7 

MALI" 

• 

.  1“ 

• 

.  I" 

;  a  J88 

PLIB 

,  VfcR 

.  vEp 

.  N/S 

otal 

9 

9 

• 

• 

!  5177 

DESCRIPTION 


TAPE,  LRECL  Ub  PR  80,  ASCII  OR  EBCDIC 
SUBROUTINE  library 
VERSATtC  PLOT  LIBRARY 


pop  ii/ao 

data  reduction  software 


I  na-E 

SIJP- 
PL  I F R 

M  A  I  T 
PfS 

SOURCE 

LINES 

DESCRIPTION 

ALLIB 

9 

.  IM 

;  ih 

•  • 

.  1 1  ?R, 

BUILD  AND  UPDATE  CALIBRATION  LIBRARY 

ALLST 

.  IM 

•  Tm 

.  lab. 

LIST  CALIBRATION  LIBRARY 

“LINE 

.  IM 

•  IH 

.  238 , 

DISCRIMINATOR  linearity  thick 

*EC 

.  I” 

.  I* 

.  23*5, 

A/O  CONVERTER  STORFO  ON  MAG  Tape 

mQac 

.  IM 

•  1* 

.  27a, 

CHECK  "EXEC'  TAPE 

"EDIT 

,  IM 

. 

.  21  R. 

RE“OVE  UNWANTED  DATA  FRO“  "E*EC"  TAPE 

MLI$T 

.  IM 

• 

.  JH 

• 

.  ?2*6, 

•  • 

PERFORM  ENGINEERING  UNITS  CONVERSION  AND 

from  "f*ec"  tape 

LIST 

MOUmR 

.  IM 

• 

•  IH 

• 

.  2  1  8 , 

•  • 

PERFORM  ENGINEERING  UNITS  CONVERSION  AND 
FRO"  "EYEC"  TAPF 

LIST 

PINJT 

.  IM 

.  IM 

load  anp  verify  DC 
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PREDICTIVE  SOFTWARE  COST  MOOEL 


CONTINUATION  SHEET _ _ DATE:  28  S?.Pt 


■pRun 

,  I" 

.  Th 

1  **6, 

RECOVER  HKII  067a  ThRqURh  nc  S  7  CiPE  O'*  TEMPORARY 

• 

• 

• 

OITA  FILE 

M 

,  If. 

.  IH 

133*1, 

RECOVER  ANALOG  pH  DATA,  STORE  on  TfHPpRAPT  DATt 

• 

• 

• 

FILE 

•CM 

.  IH 

.  IH 

2!«. 

load  AND  VERIFY  700'S  FOP  PCM  PATA/STRIP  CHARTS 

'Chain 

.  IM 

.  IH 

1608. 

RECOVER  PCm  data,  STORC  ON  'TEHPORaRY  Data  riLt 

:dF2dk 

■  IH 

,  IH  . 

75. 

STDRf  REFERENCE  DATA  FILE  On  DISK  TO  FRET  TAPE 

• 

• 

• 

DRIVE 

:ALS 

•  !h 

•  IH 

136. 

GENERATES  CALIBRATION  LIBRARY  FOR  fm  o»  PC“  Ron 

:*LfiK 

•  I* 

•  Iw 

60, 

PRINT  ANf  VERIFY  CALIBRATION  LIBRARY 

'PST  A  T 

•  I* 

.  I* 

9*7. 

PERFORM  STATISTICAL  AND  TIRE  ANALYSIS  OF 

• 

• 

• 

TEMPORARY  DATA  FILEfSI 

•PDlixP 

.  i* 

.  IH 

256. 

LIST  SELECTED  PARAMETERS  FROM  TEMPORARY  DATA 

• 

• 

a 

FILE (SI 

inMP 

.  in  , 

.  IH 

238. 

LIST  SELECTED  PARAMETERS  F»pM  TEMPORARY  paTa 

• 

• 

• 

file (S) 

’03 

,  JW 

.  IH 

602, 

CHECK  FM  SYSTEM 

•05 

.  IH 

.  IH 

165. 

CHECK  CALIBRATION  ID/TAPE  BREAK  SYSTEM 

•01 

,  Th 

.  IH 

6*>7, 

CHECK  DC  LOAD 

'0? 

.  IH 

.  IH 

S69, 

GROSS  CHECK  OF  hk I I  SYSTfH 

)C*LC 

.  IH 

.  IH 

30. 

RECOVER  m*ii  DATA  and  STORE  ON  MAGNETIC  TAPE 

JCD'JMP 

.  IH 

.  IH 

128. 

recover  mkii  data  and  store  on  magnetic  tare 

ICTES’ 

.  IH 

.  IH 

30. 

CHECK  DC 

lot 

.  IH 

.  IH 

621, 

CHECK  SIMULATOR  to  COMPUTER  COMMUNICATION'S 

ro7 

.  IH 

.  TH 

1663, 

CHECK  SIMULATOR  TO  COMPUTE*  COMMUNICATION'S 

rn9 

.  IH 

.  JH 

16«I. 

CHFCK  SIMULATOR  TO  COMPUTER  COMMUNICATIONS 

jp  I  “t 

.  IH 

.  IH 

632, 

RLAGS  TI*<e  OF  voltage  spikes 

riRE 

,  IH 

.  IH 

361, 

SEPARATE  I/O  COMMUTATED  values  FROM  up  Tp 

• 

• 

• 

5  Channels 

jatt 

.  IH 

.  I" 

120, 

separates  i/p  commutated  values 

TOTAL 

« 

• 

• 

• 

226 16*. 

MPS 

MJCPO-DATA  SYSTEMS 
INTEL  *080 


:i  name 

SUP¬ 

PLIER 

MA  IT 
RES 

FST 

SOURCE 

LINES 

description 

AL 

• 

.  In 

a  IH 

a 

a 

CREATES  A  PILE 

ENTRY 

.  In 

• 

a  I H 

• 

a 

a 

COPIES  ASCII  DATA  FROM  A  HEWLETT-PACKARD 
TERMINAL  CASSETTE  TO  A  FILE 

fast 

t 

•  IH 

a 

SETS  TERMINAL  BAUD  RATE  TO  9600 

INVASM 

•  IH 

• 

a  IH 

a 

a 

a 

CRFATtS  AN  INVERSE  ASSfHBLT  LISTING  and 

A  PSUEOO 

ISIS 

.  INTEL 

.INTEL/Ih 

0PFRATING  SYSTEM 

LIST 

•  In 

.  IH 

a 

DISPLAYS  A  F ILF  To  THE  CONSOLE 

RTYRe 

.  IN 

,  IM 

TYPE  FROM  CONSOLE  TO  LINE  PRINTER 

ROLLIN 

•  JM 

a 

,  IH 

a 

a 

a 

COPY  BINARY  Data  FROM  A  HEWLETT-PACKARD 
TERMINAL  CASSETTE  TO  A  FILE 

ROLOllT 

a  IH 

.  IM 

a 

COPT  A  BINARY  FILE  to  a  HEWLETT-PACKARD 

1979 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  - 
FLIGHT  TEST  REQUIREMENTS _ 


DATE:  28  Sept  1979 


Typically  It  will  take  about  four  to  ten  (average  about  six)  sorties  to  get 
the  system  running  smoothly  before  testing  can  begin  in  earnest.  Flight  test 
statistics  are  as  follows: 


Block  Change  Nr.  Sorties  Nr.  Flight  Hours 

F-12  13  34.2 

$10,000  per  sortie  is  used  by  SMALC  as  a  rough  cost  estimate  for  Flight  test¬ 
ing,  including  system  preparation  and  range  costs.  Calculations  based  on 
Figures  from  AFR  173-10,  USAF  Cost  and  Planning  Factors,  Volume  I,  May  1977, 
yield  a  cost  per  flight  hour  of  $2,992. 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  -  TRAINING  REQUIREMENTS  DATE:  28  Sept  197? 
PROGRAMMER  TRAINING. 

Engineering  training  is  by  OJT,  with  occasional  formal  classes  on  particular 
subjects.  These  are  normally  taught  by  one  of  the  engineering  staff  members. 


USER  TRAINING: 

User  training  occurs  via  the  user  meetings  and  user  flight  testing  of  preliminary 
OFP  tapes.  During  this  time  there  are  typically  15-20  phone  calls  by  the  user  to 
SMALC. 

A  major  problem  is  that  the  flight  simulator  tape  usually  lags  the  operational 
tape  by  about  one  year.  This  is  because  of  the  time  required  to  reprogram  the 
simulator  tape. 


J  <££»■'  uS.'r^^^vV ... . 


■** 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  MAINTENANCE  HISTORY 


DESCRIPTION  OF 

NUMBERS  AND  TYPES  OF  MAINTENANCE  ACTIONS  PERFORMED 

EACH  YEAR 

SINCE  PMRT 

SOFTWARE  CHANGE  SUMMARY  FOR  THE  F-111F 

OFP 

F-10  F-ll 

F-12 

Release 

Date  11-76  11-76 

6-78 

Change 

Requirement  Code 

Total 

A  -  Add  Capability  7  6 

10 

23 

C  -  Correct  Deficiency  9  6 

23 

38 

D  -  Delete  Capability  0  6 

5 

11 

E  -  Enhancement  17  7 

5 

29 

0  -  Optimization  1  1 

3 

5 

Total  34  26 

46 

106 

CHANGES  SOLVED  IN  F-10  (RELEASED  WITH  F-ll) 

CHANGE 

TITLE 

CODE 

F002 

MULTIPLE  WIND  VECTOR  FIXES 

C 

F004 

DATA  ENTRY  ON  POWER  UP  WITH  ALT  CAL 

C 

PUSHBUTTON  DEPRESSED 

F011 

HEADING  CONFUTATION  IN  DEAD  RECKONING 

C 

F025 

SEQUENCE  INTERRUPT  IN  THE  BOMB  MODE 

E 

F029 

DESIGNATE  SWITCH 

E 

F030 

IMPROVED  WIND  VECTOR  FIX 

C 

F034 

AILA  LATERAL  STEERING  DATA 

E 

F036 

IMPROVED  KALMAN  RE-INITIALIZATION  FOR 

E 

VISUAL  OVERFLY  FIXTAKING 

F038 

WIND  VECTOR  FIX  MODE  IN  THE  WDC 

A 

F052 

POTENTIAL  WORD  SAVERS 

0 

F054 

POST  BOMB  RUN  PP  CORRECTION 

E 

F057 

RENTENTION  OF  MTH  CORRECTIONS  IN  THE  NAV 

MODE 

E 

F077 

ECP  3073 

A 

F078 

ALTITUDE  CALIBRATION  ERROR 

C 

F079 

FIXPOINT  ID  DISPLAY  COORDINATES 

E 

F080 

ABORTING  PRESENT  POSITION  CORRECTIONS 

E 

F081 

ATTACK  RADAR  SLANT  RANGE  ERROR 

C 

F083 

BALLISTICS/SEPARATION  EFFECTS  IMPROVEMENTS 

E 

F084 

ATTACK  STEERING  SENSITIVITY 

C 

F085 

BOMBING  ALTITUDE  DISPLAY 

E 

F086 

MAJOR  CYCLE  HANGUP  -  HIGH  DRAG  WEAPONS 

C 

F087 

SYSTEM  ALTITUDE  LAG 

C 

F088 

ZERO  UNPROTECTED  CORE  AT  POWER-UP 

E 

F089 

PCO  OF  COMPUTER  ERROR  TRAPS 

E 

F090 

WEAPONS  INVENTORY 

A 

F092 

RANGE  &  BEARING  OFFSET  MODE  IMPROVEMENTS 

A 

F093 

MANUAL  MAG  VAR  ENTRY 

E 

F094 

MANUAL  BOMBING  ALTITUDE  ENTRY 

A 

F096 

TAS  ONLY  MODE  WIND  VECTOR 

E 

J 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  -  SOFTWARE  PACKAGE  MAINTENANCE  HISTORY _ PATE:  28  Sept  1979 


CHANGES  SOLVED  IN  F-10  (RELEASED  WITH  F-ll)  (Continued) 

CHANGE  TITLE 

CODE 

F099 

ODSS  COMMAND  FLIGHT  VECTOR  MODE 

A 

F101 

CCIP  DEPRESSION 

E 

F103 

MANUAL  MAG  VAR  ENTRY 

A 

F105 

IMPROVED  WIND  VECTOR  FIX  ROUTINE 

E 

F106 

SSP  ELEVATION  DISLAY 

E 

CHANGE 

CHANGES  SOLVED  IN  F-ll 

TITLE 

CODE 

F026 

TERRAIN  ELEVATION  CALIBRATION 

D 

j  F037 

HEADING  FIX  MODE 

A 

F056 

ALTITUDE  CAL  MODE  LIGHT 

A 

F058 

MAG  VAR.  DR  TO  I  MODE 

E 

F060 

FOUR  OAP  CAPABILITY 

A 

F064 

INFLIGHT  ALIGN  -  INITIAL  INS  HEADING 

C 

F108 

HOMER  SET/HOMER  TRACK  AND  FIXPOINT  ID 

A 

F109 

RADAR  CURSORS 

C 

F110 

FIX  MODE  SWITCH 

E 

Elll 

NDU  DISPLAY 

E 

FI13 

BALLISTIC  LEAD  AND  LAG 

A 

F114 

HIGH  ALTITUDE  CALIBRATION 

A 

E116 

COMPUTER  HALT  WITH  INVALID  SSP  SELECTION 

C 

FI18 

TIMESAVER,  32  PER  SECOND  RATE  GROUP 

0 

FI22 

GROUND  AVOIDANCE  INDICATION 

E 

F123 

DRIFT  AND  LEAD-INTO-TURN  LIMIT  IMPROVEMENT 

E 

F124 

APQ-144  BEACON  OPERATION 

E 

F125 

INERTIAL  WIND  VECTOR  FIX 

D 

F126 

RECON  TABLES 

D 

F127 

ROCKET  DELIVERY 

D 

F128 

RANGE/BEARING  OFFSET  TABLES 

D 

F129 

BEACON  BOMBING  IMPROVEMENT 

E 

FI  30 

DELETE  HIGH  TOSS  MODE 

D 

FI  31 

ILLEGAL  CCU  ADDRESS  SELECTION 

C 

FI  32 

RE-SCALING  OF  TFRIFV 

C 

F181 

YIELD  CODE  8  BLAST  RADIUS 

C 
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PREDICTIVE  SOFTWARE  COST  MODEL 

CONTINUATION  SHEET  -  SOFTWARE  PACKAGE  MAINTENANCE  HISTORY _ DATE;  28  Sept  197 


CHANGES  SOLVED  IN  F-12 


CHANGE  TITLE  CODE 


F018  CONVERT  SET  BITE  FAILURE  REPORTING  C 

F098  OBSOLETE  RMAX  DATA  IN  MANUAL  BALLISTICS  MODE  C 

F112  BALLISTICS  LOADING  A 

F117  INACCURATE  BALLISTICS  COMPUTATION  IN  C 

TRANSONIC  REGION 

FI20  INS  MODE  LIGHT  A 

F133  BALLISTICS  DATA  FOR  CBU  52/58/71  A 

FI 34  RIVET  GYRO  CS  BITE  C 

FI 39  LADD  SAFE  ESCAPE  C 

F140  RECON  POINT  ELEVATION  C 

F141  ALTITUDE  DRIFT  DURING  HIGH  ALTITUDE  CAL  E 

F142  PCO  ERROR  TRAP  EXPANSION  A 

F143  MISSION  DESTRUCT  0 

F144  PANEL  LOCKOUT  DURING  DATA  ENTRY  C 

F145  RECON  TABLE  SYNCHRONIZATION  C 

F148  RECON/BOMB  MODE  MECHANIZATION  C 

F150  ANALOG  BAR  COMPUTATIONS  0 

F156  REMECHANIZATION  OF  LADD  MODE  E 

F157  MK  106  BLAST  RADII  A 

F158  SUU  21  CERTIFICATION  A 

F159  REVISE  BALLISTICS  LIST  A 

F160  UPDATE  EXISTING  BALLISTICS  A 

F161  BALLISTIC  WIND  CAPABILITY  A 

F169  DELETE  FIXPOINT  AUTO  SEQUENCING  D 

F170  DELETE  YIELD  CODE  "9"  D 

F171  MOVE  CVF  70  ODS  E 

FI 7 3  B43  BLAST  RADIUS  E 

FI  75  REMOVE  LEAD/LAG  LIMITS  E 

FI 78  DELETE  AUTOMATIC  WEAPONS  BAY  DOOR  OPENING  D 

DURING  WEAPONS  DELIVERIES  FROM  LEFT  OR 
RIGHT  BAY 

F179  THE  AIRCRAFT  CAN  CARRY  DIFFERENT  WEAPONS  ON  A 

STATIONS  3/6  AND  3A/6A  BUT  THE  WSO  CAN  ONLY 
ENTER  THE  WEAPONS  LOC  AND  ID  FOR  ONE  OF 
TH’.SE  WEAPONS 

FI 80  DELETE  WORDS  ASSOCIATED  WITH  WEAPON  STATIONS  D 

F182  ARS  NORTH  ORIENTATION  D 

FI 3 5  MEMORY  ADDRESS  COMPUTER  HALTS  C 

FI  27  MANUAL  NAV  MODE  REMECHANIZATION  C 

F188  -XT  DEPENDENT  WPN  INCORRECT  BALLISTICS  C 

F189  GLIDE  ANGLE/DIVE  DISPLAY  IN  DIVE  C 

F190  MANUAL  NAV  CURSOR  CONTROL  C 

FI 91  A/A  SELECTION  -  PARTIAL  BOMB  MODE  ENTRY  (GNC) 

F192  ANALOG  BAR  NOT  STOWED  UPON  A/A  GUNS  EXIT  C 

F193  VISUAL  BOMB  STEERING  C 

F194  INTERMITTENT  SEQUENCING  IN  VISUAL  BOMB  C 

F195  NO  INS  CONTROL  VECTOR  -  WDC  ONLY  C 
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PREDICTIVE  SOFTWARE  COST  MODEL 

CONTINUATION  SHEET  -  SOFTWARE  PACKAGE  MAINTENANCE  HISTORY _ DATE:  28  Sept  1979 

CHANGES  SOLVED  IN  F-12  (Continued) 


CHANGE  TITLE  CODE 


F196  RANGE  ITERATION  -  OPTIMIZATION  ERROR  C 
F197  GNC  011/101  ERROR  TRAPS  C 
F198  AUTOMATIC  ROUTE  POINT  SEQUENCING  IN  VO  UPDATE  C 
F199  PITCH  STEERING  IN  RIPPLE  HOMS  MODE  C 
F201  FILTERCYCLE  INITIALIZATION  C 
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PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  MAINTENANCE  COST  HISTORY _ 

YEARLY  COST  OF  MAINTAINING  PACKAGE: 

Manhours  expended  in  support  of  the  F-111F  are  as  follows: 


DATE:  28  Sept  1979 


■FY77 

FY78 

FY79 

Direct  F-111F  Support 

16,926 

8,877 

20,243 

Support  Software'*’ 

23,790 

29,776 

21,094 

Manhours  by  block  change  are  shown  on  p.  C- 79. 


Vendor  support  of  the  Harris,  Interdata  and  PDP  computers  costs  $308K/year  plus 
$126K/year  for  expendables  and  prototype  hardware  (split  about  50/50). 


1.  For  FB-111A,  F-111D  and  F-111F,  plus  other  projects. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  -  MAINTENANCE  COST  HISTORY 


DATE:  28  Sept  1979 


Block 

F-10 

(released  11-76) 


A  C  D  E  0 


7  9  0  17  1 


Total  Manhour  (FY77  -  FY79) 


F-ll 

(released  11-76) 
F-12 

(released  6-78) 
F-13 

(scheduled  for 
release  late 
1979) 


6  6  6  7  1 


10  23  5  5  3 


34,629 


11,024 
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PREDICTIVE  SOFTWARE  COST  MODEL 


HISTORICAL  DATA  SOURCES 

Data  Base  Name 
Location 
Contact  Person 
Phone  Number 
General  Contents 

Period  Covered 
Data  Quality 


DATE: 


F/FB-111  Operational  Flight  Program 
SM-ALC/MMECP,  McClellan  AFB,  California 
Alton  E.  Patterson 
(916)643-4762 

Manhours  by  Fiscal  Year  by  function/ 
project 

FY'77  through  FY’79 

Good  detail  on  expenditure  of  manhours, 
down  to  level  of  OFP  block  change 
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PREDICTIVE  SOFTWARE  COST  MODEL 


RECOMMENDATIONS  RE  SOFTWARE  SUPPORT  COST  PREDICTING _ DATE:  28  Sept  1979 


RESPONDENT:  Bassett 


If  you  were  responsible  for  predicting,  accumulating  and  accounting  for  software 
j  support  coses,  how  would  you  do  it? 

j 

1.  AF  Flight  simulator  concept  (requirements  different  than  A/C)  -  Need  to  be 
j  able  to  update  flight  simulator  by  just  changing  OFP  software. 

!  2.  a.  Demand  spare  memory 

b.  Language  -  Function  of  application 

Need  to  study  tradeoff  between  ease  of  development /maintenance  vs. 
operational  requirements  (efficient  code) 

Can  HOL  support  those  requirements? 

Support  -  peculiar  language  -  need  to  buy  original  contractor 

c.  Mission  requirements 

TAC  has  more  precise  testing  requirements  than  SAC. 

(Weapon  delivery  precision)  [smart  weapons] 

d.  SPO  is  not  motivated  toward  economical  support 

AFLC  needs  veto  power  over  design  decisions 

Similarities  among  aircraft  avionics  are  greater  than  differences. 

e.  Analysis  and  design  and  testing  overwhelms  compilation/assembly. 

f.  Support  personnel  cost  more  than  development  personnel 

(Need  system  knowledge.  Implies  experience.) 

•  Autonetics  -  $65K/man  year 

GD  -  $35K/man  year 


•'  lUdTi"  «*wf«.  •  <**■*•  afc^ 


APPENDIX  D 


F/FB-111  SUPPORT  SOFTWARE/ SMALC  DETAILED  DATA 
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PREDICTIVE  SOFTWARE  COST  MODEL 
FIELD  EVALUATION  REPORT 

GENERAL  SOFTWARE  PACKAGE  DESCRIPTION _ DATE:  28  Sept  1979 


ALC:  SM 

WEAPON  SYSTEM:  F/FB-111  Support  Software 

SOFTWARE  PACKAGE:  Simulation  Software 

PERSONNEL  CONTACTED: 


A1  Patterson,  MMECP 
Lynn  Bassett 
Jack  Claar 
Nan  Teague 

SOFTWARE  PACKAGE  CHARACTERISTICS: 

SI2E;  300K+  words  in  core  (source  lines  and  data  files) 

LANGUAGE:  75  percent  Fortran,  25  percent  Assembly 

APPLICATION:  Simulation  of  F/FB-111  Operational  Environment 

COMPLEXITY:  High 

YEAR  DEVELOPED:  1974 

DEVELOPER:  General  Dynamics 

COMMENTS 

HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS: 

MANUFACTURER:  Harris 

MODEL  NUMBER/DESIGNATOR:  Harris/4 
WORD  SIZE:  24-bit 
MEMORY  SIZE:  6  X  80K  =  480K 
memory  fill:  Virtual  System 

WEAPON  SYSTEM  USE: 

number  OF  users  MMECP  OFP,  Test  and  Simulation  Engineers 
LOCATIONS  OF  USERS.  SM-ALC 

FREQUENCY  OF  USE:  Daily 

INTERVIEWER(S):  R.  B,  Waina,  A.  P.  Bangs 
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PREDICTIVE  SOFTWARE  COST  MOO  EL 


CONTINUATION  SHEET  -  QUALITY  ATTRIBUTES 


Rate  the  Package  on  the  following  Quality  attributes: 


PATE:  28  Sept  1979 


Accessibility:  9 
Accountability:  7 


Access  Audit: 


Access  Control:  10 


Accuracy:  10 
Augmentability :  9 

Clarity:  5 


Communicativeness : 


Communications,  Commonality:  N/A 
Completeness:  9 

Conciseness:  10 
Consistency: 

Internal  Consistency:  8 
External  Consistency:  N/A 

See  Accuracy 

Data  Commonality:  N/A 

Efficiency : 

Execution  Efficiency:  10 
Storage  Efficiency:  10 

Error  Tolerance:  10 

See  Augmentability 

Generality:  9 

Human  Engineering  8 

Independence: 

Device:  1 

Software  System:  1 


See  Testability 
Interoperability:  N/A 


See  Access  Control 


Legibility:  9 
Maintainability:  9 
Modifiability:  See  Maintainability 
Modularity:  See  Conciseness 
Operability:  10 
Performance:  See  Efficiency 
Portability:  See  Independence 

Reliability:  10 


Robustness:  9 


Reusability:  5 


Selfcontainedness:  10 


Selfdescriptiveness :  1 

Simplicity:  8 


Structuredness:  7 


Testability:  N/A 
Traceability:  5 
Training:  6 

Understandability :  See  Legibility 
Usability  (as-is  utility):  See  All  Above 
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PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  PERSONNEL 


ALC:  SM 


KEY  PERSONNEL/OGRANIZATION: 


DATE: 28  Sept  1979 


OFFICE  SYMBOL:  MMECP 


MMEC 

Mr.  Robert  Green 


MMECP 

Mr.  AI  Patterson 
F/FB-111 


MMECM 

Mr.  Frank  Davis 
Software 
Management 


MMECS 

Major  Hank  Garretson 
Adminis  tration 


MMECF 

Mr.  Bob  La  Vergne 
Ground  Communica¬ 
tions,  Electronics, 
and  Meterological 


TOTAL  ASSIGNED  PERSONNEL  (NUMBER  &  TYPE):  (MMECP) 

4  Air  Force  (2-3  years  experience) 

19  Civil  Service  (3-5  years  experience) 

30  General  Dynamics  (2-3  years  experience) 

31  Autonetics  (8-10  years  experience) 


TOTAL  PACKAGES  MAINTAINED  (NUMBER  &  TYPE): 


7  -  one  OFP  for  each  of  the  two  computers  (GNC  and  WDC)  for  each  of  the  three 
aircraft,  (F-111D,  F-111F,  FB-111A),  plus  one  OFP  for  the  NCU  computer  program 
for  all  three  aircraft.  Additionally,  much  simulation  and  support  software  is 
maintained,  and  numerous  special  projects  are  carried  out. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  WORK 

DISTRIBUTION 

DATE:  28  Sept  1979 

DESCRIPTION  OF  WORK  PACKAGE  DISTRIBUTION,  INCLUDING  RESPONSIBILITIES  AND  DEGREE  OF 
SPECIALIZATION  OF  AF/CS/CONTR  PERSONNEL<MMEcp) 

NUMBER  OF  PERSONNEL 

FUNCTION 

AF  CS 

CONTR 

Management /Secretary 

4 

3 

FB-111A  S/W  Engineering 

1 

5 

F-111D  S/W  Engineering 

1 

5 

F-lllF/Pavetack  S/W 
Engineering 

1 

5 

Mission  Programs 

1  3 

F-lll  A/E  Acquisition 
Support 

2 

1 

F-lll  AISF  Enhancements 
and  S/W  Support 

15 

F-lll  OFP  Mk  11  V  &  V 

3 

3 

Flight  Test  Support 

5 

S/W  Configuration 
Management 

4 

TSU 

5 

Special  Projects 

2  5 

10 

Major  AISF  Upgrades 

[5-10  off-premise] 

4  19 

61  [+  5  -  10] 
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PREDICTIVE  SOFTWARE  COST  MODEL 
CONTINUATION  SHEET  -  WORK  DISTRIBUTION _ 


Manhours  for  FY'77  through  FY*79  are  distributed  as  follows: 


DATE:  28  Sept  1979 


Function 

FY'77 

FY'78 

FY'79 

FB-111A 

18,041 

15,069 

9,809 

F-111F 

16,926 

8,877 

20,243 

F-111D 

13,880 

19,376 

14,373 

Other  F-lll 

6,391 

3,288 

6,467 

Support  Software 

23,790 

29,776 

21,094 

Special  Projects 

28,982 

35,224 

33,548 

Leave/Holiday 

19,904 

23,580 

24,597 

Total 

127,914 

135,190 

129,131 

PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  COST  ACCOUNTING  SYSTEM  _ DATE:  28  Sept  1979 


SMALC  uses  a  manhour  accounting  system  which  logs  manhours  by  project.  For  each 
specific  aircraft  type  block  change,  manhours  are  accounted  for  by  five  functions: 
management,  definition,  development,  documentation  and  test.  There  is  also  a 
category  for  OFP  Group  Management.  Beyond  that,  individual  functions  (e.g., 
configuration  management)  and  projects  are  tracked. 


PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES 


DATE:  28  Sept.  1979 


SUPPORT  PHILOSOPHY: 

Simulation  software  is  supported  on  an  "as  required"  basis. 
Changes  are  made  as  necessary  to  react  to  changes  in  OFPs, 
respond  to  new  simulation  requirements,  correct  errors  and 
achieve  increased  operating  efficiency.  Changes  are  made  con¬ 
tinuously  rather  than  in  blocks. 


CHANGE  CONTROL  METHODS: 

FORMAL  OR  INFORMAL:  Semi-Formal 


CHANGE  REVIEW  PROCESS: 

Steering  Committee  Review  Board  and  simulation  personnel 
review  proposed  changes  in  accordance  with  the  Charter  for  the 
MMECP  Steering  Committee.  See  pp.  D-8  through  D-27. 


CONFIGURATION  IDENTIFICATION  METHODS: 

No  formal  methods  exist.  Identification  is  by  reference  to 
current  program  listing.  More  formal  methods  are  being  developed. 

CONFIGURATION  CHANGE  CONTROL  METHODS: 

Configuration  is  controlled  in  accordance  with  the  Charter 
for  the  MMECP  Steering  Committee. 

CONFIGURATION  STATUS  ACCOUNTING  METHODS:  Informal. 


SOFTWARE  LIBRARY  CONTROL  PROCEDURES:  Standard  library  procedures 
for  utility  routines. 
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CHASTpn  Ftl»  ThF  mM£Cp  STFEPING  Cf,MMITTFE 


1.  SCOPE 


This  document  establishes  the  curpna*  and  Sene#  . 
of  the  M*-'Ecp  Steering  committee. . . . . 


2.  JMTPtjPiicTlON 

The  Avionie*  Software  Section  fi'MECP)  <6  responsible  for  erq1n*ertnq 


support  of  aircraft  Operational  F'iaht  PrnQrjts  (OFP's)  assigned  to 
the  Sacramento  Afr  loaistics  Center  Csm»alCT,  This  includes  the 
eoqineerina  reauiredi  to  investigate  and  aoBlv*e  OFP  problems,  ne» 


reou  i  recent  s  and  oef  i  c  i  enc  4  es  j  to  develop  prototype*  test  and 


evaluate  o  FP  unhjt*s  and  mod ( f i c a 1 4  on s j  to  4ntearate  the  OFP's  with 
the  av4onics  systems)  to  maintain  the  nFp  avionics  svste"  nerformancet 
to  m  a  i  p  1 1  n  OFP  eon  f  1  Surat  1  on  and  documentation.  It  also  Includes  the 


engineering  reauired  to  develop  and  Implement  OFP  support  resource®. 
The  Section  is  divided  into  four  functional  groups.  Those  groups, 
and  their  responsibilities,  are  as  follows! 

A.  Tt<e  UPerational  Flight  Program  (OFP)  group  is  responsible  for 
overall  management  of  the  F«111  "block  change"  Cycle  which 
include*  a'l  changes,  mod ! f i e at i on* «  res t rue t u r i no  or  recoding 


of  the  Embedded  Computer  Svstem  (EC.S )  software. 

B,  The  Software  System  work i ng  f SSW)  group  is  deleosted  the  resPon- 
ibility  for  planning  and  Performance  of  tasks  supporting  the 
OFP  qroup,  hoth  in  software  and  hardware. 

C.  The  Svstem  development  and  Integration  orouo  (sBI)  is  resnoneible 


for  a  variety  o*  tasks,  Including  the  Test  anrt  Evaluation  o*  the 


ECS  software. 


2I,2  CONFjCHARTFR  , SC 


0.  The  Con  f  1  gurat  1  on  Management  (C*)  group  4a  responsible  Tor 

Configuration  Identification,  Control  and  Status  Accounting  o< 
all  changes  to  the  PCS  software  and  all  changes*  both  hardware 
and  software*  to  the  suroort  eoulpment. 

3,  PURPOSE ! 

The  oueoose  of  the  SteeHng  Committee  (SC)  Is  to  review  all  wort 
(either  new  work  or  proposed  changes)  that  falls  within  the  Scone 
of  resoons 1 h 1 1 1 t v  of  the  fMFCp  Section,  mo  work  shall  he  considered 
except  that  work  nroooged  on  a  Task  ReOuast*  and  delivered  to 
Conf 1 aurat 1  on  Management.  (For  Instructions  on  a  Task  Reouest*  see 
Task  Reouest  Form,  Instruction  For  Preparing  Task  Reguest  Form, 
and  Guidelines  For  Task  Request),  The  work  or  changes  proposed  are 
not  limited  to  software  e*c l us  1 v e 1 v »  changes  to  hardware#  procedures* 
policies*  mannlnq*  etc**  end  any  Other  change*  which  will  Improve 
the  ooeratlon  or  efficiency  of  the  Section*  or  that  will  imorove 
Ita  ef7 ectTveness  In  the  accomo 1 1 shment  of  the  mission,  mav  be 
orooosed, 

<t,  organization! . 

The  Steering  ronmittem  *i'l  t;e  comprised  of  tie  "  ’  E  L  H  Section  Chief 
(Chafnmen)  nr  MS  H.sirniif  ,  the  configuration  •"  a  n  a  n  e  r  (Secretary)* 
the  SSw  group  leader,  ft  “s>T  group  leader*  a  represent  at  1  ve  from 
t*’*  OFP  lrpi.ini  on’!  ot^er  "embers  as  deslgoatco  ty  the  SC  Chai»man, 
These  members  will  ^ecHe  «hat  action  is  to  he  take-  on  all  M‘ECP 
Task  Reouests*  T*^ese  members  will  also  cnnvev  Information  hack  to 
th*lr  respective  nmuns.  “TF  roup  members  will  fe  rpouested  to  attend 
whan  their  technical  expertise  Is  reuulred). 
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*PPL ICAPILI TV  t 

Task  Requests  m* y  be  submitted  by  a"tone  associated  with  the  MMfCP 
Section,  These  Include  the  M*ECP  Personnel  themselves,  the  Personnel 
easloned  tn  mmecp  from  the  Comptrollers  Office  (ACD)»  the  Software 
Support  Center  (MA1T),  the  Poekwell  Internet  1  onel  end  General 
Dynamics  contractor  Personnel,  Inputs  may  also  be  received  from  other 
Sections  In  the  MMEC  Branch  whose  work  or  requirements  Impact  or 


are 

Impacted  bv  tt 

<e  M 

M£CP  effort. 

The 

normal 

channel 

for  eommun 1  cat  “ 

1  ng 

to  other  Sec*l 

oos 

on  natters 

re ’  at 

1  nq  to  r. 

onputer 

resource 

aH 

ocatlon  Is  the 

Rea 

oruce  lit  1  H  Z 

at  1  on 

Board, 

a  Branch 

level  board 

whose  ♦ unc 1 1  on  i t 

1  s 

to  assure  op 

t  1  ms1 

use  of 

aH  computer  resources. 

The 

Cnn  ft  nu r a  t i nn 

M„n 

aoer  Is  the 

hMECP 

Sec  1 1  on 

’s  Perma 

nent  member 

of 

the  SP«ource  Ut 

■111 

ration  Board 

and 

will  Inc 

lude  on 

the  SteeMno 

Comm  1 1 1 ,  e  Agenda  all  requests  from  these  other  Sections,  The  normal 
channel  for  resoondlnn  to  other  sections  on  action  taken  on  their 


requests  Is  again  throuoh  thc  Resource  Otlliatlon  Board,  when  the 


"aonltude  of  the  rem/P8f  Is  too  broad  to  be  e*oea1 t 1 ous 1 v  hanoled 


♦rrcuoht  the  workings  of  the  *C'  the  SC  C  ra 1 r»  an  w  <  1  i  accept  the 


r  -  s 1  1  ,o' 

t 

and  nee  1  ml rect  1  v 

w 1 1  n  the 

ofnar  .Section  Ch<ef(s) 

i  nyrl  v(*H 

and/or  wit"  .he  french 

CM  ef  until 

50m#* 

resol ut Ion 

*  9 

reached. 

The  Chairman  vlll  then  renort 

back 

to 

the  SC  On  the  dis- 

POS 1 t 1 pn 

of 

the  Task  Bequest  so 

that  the 

sc 

mav 

work  toward 

•ccom- 

Dl <  Sh 1 nq 

the 

qoa's  decided  on. 

ACTTObSt 

The  SC  will  rev(ew  al '  work  submitted  to  Conf 1 qurat 1  on  Management 
and  Hated  as  an  item  o"  the  Aqende, 

A ,  where  the  SC  decides  the  task  requested  on  a  Task  Request  csnnot 


or  shou'd  not  be  accomplished,  the  task  will  be  disapproved. 


24J,  CDNF  tCMABTFH  ,SC 


6,  wh*r*  the  SC  decide*  the  task  requested  4*  clearly  necessary, 
the  SC  win  approve  It  for  Implementation  Pending  receipt  of 
the  Task  Schedule.  The  Task  Request  will  be  sent  directly  to 
Operational  Flight  Program  fOFP)*  Svstem  Development  and  In- 
tegratlon  (SOI),  or  SuPPort  Software  (SS*0  Functional  Group  where 
Task  Schedule  assignments  will  he  made.  A  Task  Resources  Alloca¬ 
tion  and  Schedule  (which  will  be  referred  to  as  Task  Schedule  In 
in  this  charter)  will  be  prepared,  showina  the  cost  (both  |r 
manpower  and  resources)  reaulred  for  its  completion  a"d  the 
estimated  time  frame  during  which  the  t8ak  can  be  accomplished 
(for  Instructions  on  a  Task  Schedule,  See  Task  Resources  Alloca¬ 
tion  and  Schedule  Form*  Instructions  For  Preoarlna  Task  Resources 
Allocation  and  Schedule  Form,  and  Guidelines  For  Task  Resources 
Allocation  end  Schedule  Form),  *11  Task  Schedules*  regardless  of 
to  whom  assigned*  will  be  completed  end  provided  to  Conf 1 ourat 1  on 
Management  o r 1 o r  tc>  the  next  SC  meeting  which  will  normally  be 
five  working  davt  alter  the  Task  Reauest  has  been  aoproved  for 
Implementation  bv  SC.  Any  Task  Seheduie  not  delivered  bv  that 
t ir e  will  be  logged  as  Delinquent  and  the  appropriate  group 
leader  advised  to  that  he  may  take  remedial  action,  where 
the  SC  concludes  that  the  Task  Reguest  can  be  accomplished 
after  examining  the  Task  Schedule*  the  SC  will  approve  th*» 

Task  Reduest  for  Implementation!  however*  where  the  SC  concludes 
that  the  Task  Reguest  cannot  be  accomplished*  the  SC  will 
disapprove  the  Task  Request, 
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C,  when  there  jre  several  vlahle  alternative  wavs  of  accomo I  1 sh 1 ng 
the  l»sk»  and/or  the  task  Is  of  such  magnitude  and  co9t  that  the 
SC  needs  extensive  Information#  a  Feasibility  Stuov  will  he 
requested#  The  assignment  mechanism  will  be  the  sa^e  as  that 
for  t  h  a  Task  Schedule  described  In  the  Paragraph  above  e*eer>t 
that  the  schedule  will  be  for  completion  of  the  Feasibility 
Study.  The  completed  Feasibility  Study  will  Include  a  Task 
Schedule  for  Implementation  ano  will  be  delivered  to  Con f 1 gu ret 1  on 
Management  for  inclusion  on  the  SC  Aqenda,  The  SC  will  review 
the  Feasibility  Study  ang  either  approve  all  or  a  portion  of  the 
Feasibility  study  for  1 »o 1 emen t a 1 1  on  or  disapprove  the  task, 
where  the  SC  approves  all  of  the  Feasibility  Studv  for  1  mo  1 e»tn t a“ 
tion.  the  status  o*  the  Task  Request  from  which  the  Feasibility 
Studv  was  developed  will  be  changed  from  Studv  to  l«pl e»*nt8t lor# 
where  the  SC  approves  a  portion  of  the  Feasibility  Studv  for 
Implementation  then  the  Tagl#  Request  from  which  the  Feasibility 
Studv  was  develdPed  will  he  closed  out  and  one  or  more  Task 
Wenuests  reflection  the  approved  portion  of  the  Feasibility 
Studv  will  be  submitted  to  the  SC  for  approve', 
b.  The  completion  date  for  any  original  schedule  mav  be  changed 
once  by  a  verbal  report  to  the  SC  as  lonq  as  the  date  does  not 
change  hy  «ore  than  30  days.  Any  other  changes  to  the  date  on 
the  schedule  form  will  be  accomplished  bv  submitting  a 
revised  schedule  form, 

E ,  where  the  Task  Reoues t  has  been  Implemented  and/or  completed#  a 
Task  Closure  Form  will  be  completed  a"d  provided  to  Conf 1 gurat 1  on 
Management  ffor  Instructions  on  a  Task  Closure#  see  Task  Closure 
Form,  inst-ucMon  for  Pr*r»rina  Task  Closure#  and  Guidelines  for 
Task  Cl ©sure  )  , 

C  0  mf|C  mar  TFiTTsC  -----  S 
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guidelines'  for  task  request  form 

SCOPE! 

This  kocui'e'it  establishes  the  reaul  rement  tor  use  of  the 
Task  Reouest  form  when  making  ehenqes  to  the  software  or 
hardware  within  the  F • 1 1  I  Avionics  Integration  Software  Far < I  I  tv 
C*ISF).  Th<s  for*  eao  he  utifi*ed  hv  e<  vl  I  Un>  a1Ht»rvi  or 
contractor  personnel. 

APPLICATION! 

The  Tgsk  Request  Is  to  he  prepared  hv  any  Individual  who  orecelves 
a  need  that  reQuIres  a  ch«ng«  to  software,  haraward,  Droceoures  or 
priorltes  that  are  “Ifhln  the  scope  of  control  of  the  Avionics 
Software  Setlon  (MMffCP),  Configuration  hanaoe»ent  tCff  reoulres 
this  form  aS  a  vehicle  (a)  to  provide  Information  for  the  Steering 
Committee,  ISC),  Cb )  to  provide  the  Information  reauried  for  CM  to 
prepare  the  Agenda  and  to  keen  the  status  loos  required  bv  the 
Steering  Committee!  and  Cel  to  control  change*  to  the  software 
Cor  hardware)!  thus  assurTna  that  the  eonf igurat ion  is  accuratelv 
reflected  in  t  he  document  at  Ion. 

PE S P Ob siRTLTTIER  OF  the  ORIGINATOPj 

A,  Preoares  the  Task  Reouest  form  (TR) 

B.  Preoares  a  *  reaul  recent  s "  docunentl 

1.  *  new  software  program!  or  m8|or  change*  to  a  nroor»», 

reguires  the  use  of  ■  requirements  document.  In  brief,  the 
requirements’  document  establishes  the  Performance,  design, 
development,  end  test  requirements  for  a  Program  and  will  be 
used  s*  th»  wdesTgn*T©1’  document^  IT  must  be  detei  1  ed 
enough  to  specify  inputs,  outouts,  snd  pertinent  Intense- 


Zi,7  COh'FiCHARTER  .SC 


1n0  with  oe  r 1  oh#  re  1  eaule'ment,  etc.  It  will  also  be  the 
orjgl natof'i  responsibility  to  run  the  program  against  a 
test  case  using  operating  Instructions  delivered  with  the 
program,  to  cheek  that  the  program  meets  the  requirements 
of  the  Task  Raauest,  to  notify  CM  when  the  Job  has  been 
completed  (tasting  completed),  and  to  coordinate  on  the  Task 
Closure  form, 

2.  M1nor  changes  to  a  program  already  In  use  requires  only  a 

detailed  list  of  requirements  Indicating  exactly  all  function* 
to  be  Performed  fey  the  computer  program  e*pressed  In  methe* 
"atlcal,  loaleel  and  operational  terms,  together  with  all 
relevant  rules  and  tolerances.  Also  Include  details  of 
Input,  output,  all  Pertinent  Interfacing  with  Peripheral 
equipment  and  Identify  the  means  hv  which  th#  eventual  per¬ 
formance  of  specified  functions  will  he  verified  during 
formal  testlnq. 

C,  Submits  the  Task  Request  form  and  the  "reoul rements"  document  to 
CM  in  one  "naekaqe", 

cm  responsIpTl r t ifs » 

A,  loa»1n  and  asslon  a  control  number  to  the  Task  Request  (TP), 

B,  Add  the  Task  Peauest  to  the  Steering  Committee  agenda,  and 
forward  the  Task  Request  and  " reoul rement s"  document  to  the 
Steering  Committee  for  action, 

C,  If  turther  action  is  approved  by  the  Steering  Committee, 
forward  the  Task  Request  end  the  " regul rements"  document  to  the 
responsible  group  leader, 

n  ,  Develop  the  Steering  Committee  minutes  showing  actions  taken, 
and  distribute  to  a''  arour  leaders  so  they  may  Inform  those 
Individuals  within  rr-elr  resoecMve  groups  whose  tasks  have  been 
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task  reddest  form 
titlF: 


CCl.  no,j 


hate  of  shpmittal: 


'EED  QA  T£j 


TASK  TVPF:  MF.K  NOD  S/W  H/w  MRMT  TrNG  CONFIG 

system,  tntfppata  Ite  s<>o/65  u-pi  Mos  agero  t7  f/fr  o  )  Harris  dts  ] 

OTHERS 

STATEMENT  of.  PRi.’aLE”! _ 

. ••••■*■••••••••••■;*••!••••••••••••  -SB«*S»  *J» 


Proposed  solution. 


/IIS  T  TF  ICATIOH  (PBIOPlTYl/f  IMPACT)  I 


• 

*$TEF*r*G 

* 

COMMITTEE 

action:  date: 

♦ASSIGNED 

* 

TO  (GROUP 

REP) « 

•COMMENTS: 

nrmrnTfrm 
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INSTRUCTIONS  F0«  PREPARING  TASK  REQUEST 

i*e  task  r*au«»t  originator  4s  reaul red  to  complete  each  blank  either  In  (nk 
or  typed*  e*eePt  as  stated*  Ao  not  *r J  t*  _beJow_tbe,  lLne-Oi,  _*  'a. 


TITLE  i  .......  _ _ _ 

Brief*  descriptive  title  for  the  task  being  considered. 

CCL  NOj 

Conf  1  qurat  |  on  Management  (Cm)_“LU _ assTon  this  ougEiar^at _ the  tiire-Of 

1 od“l  n. 

ORIGINATOR j  _  ~  . 

Enter  the  08*6  of  the  Lodi  visual  _jjfil£aJJ.Y  ieip_Q04_ihl_e  far  originating 
the  fa*1*  I"ev  be  aetua1  or|a|i->ator  or  8nv  other  Person  dealqnatedl  e.Q.* 
group  leader,  Section  chi  ef*__etc-»  _ _ _  _  . 

date  oe  sljb.mit tali _ 

Enter  the  date  that  this  form  Is  submitted  to  C on f I gu r a 1 1  on  Manage"ent, 
NEEO  PATE  i 

Enter  the  date  that  the  per_jon_  r^qu^sj Jng  „tJie_ task  needs,  .the  task  to  t>e 
completed  ra  meet  some  reoulrement  or  milestone. 


TASK  TYPEl 

Circle  applicable  answer (s)_. 


-fSTEMt  . _  .  _  _ _  _ _ _  . 

Circle  applicable  answerfs)j  for  the  OTS  and  the  Harris*  specify  If  It 
la  for  the  «f/Er"  or  "0"  "odel  .  _ _ _ 

Statement  of  PROHI  EM|  _  _  _  _ _ 

A  brief  Description  of  the  SVmptoms  Of  an  existing  problem  or  the 
Possibility  of  a  future  problem  fpr  which _ the  task  Is  Initiated. 

PROPOSED  SnilJTIONl _ 

A  s-iogested  solution  (or  reoulrement  of  a  solution)  deemed  necessary 
by  the  orlgnletor,  _  _ _ _ _ _ 

Nofjt  Th| a  dOas  not  Imply  that  any  rtou I rement  8  stated  here  will  absolute 
or  even  "eeessarlly  desirable*  but  only  exists  to  provide  a  basis 

fpr  dlacusslpn  between  the  originator*  approval  authority*  s"d _ _ _ 

development  whleh  will  determine  a  mutually  agpeeahle  solution, 

a  mutually  soreeab'e  solution)  _  _ _ _ 
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JUSTIFICATION  (PRIORITY) /(IMPACT)  i 


Enter  the  priority  the*  the  development  manaoer  thinks  should  be  Pieced 

to  mission  Performance  “h<eh*  If  not  solved*  will  have  direct  Impact  on 
-SM-ALC  m 1sa1o"»  PRIORITY!  Problems  which  see  higher  In  atatua  than  >»u*lne 
which*  If  not  solved*  will  become  elevated  to  EMERGENCY) 


ROUTINEi  Probltm.s  whi-cJi  aJe_-anc.ftim-I_a.r- ad. .durlna.  the. normal _ _ _ 

course  of  business  which  can  be  solved  with  an  adedUate  lead  time  ano 


which  does  not  greatly  Impact  mission  Performance  and  enhancement  th»t _ 

are  not  absolutely  nece*iarv  or  does  not  greatly  Impact  mission  per- 

.. _ f  Oemanee, Juatlfv  the  taek  ba^ed  on  the earn  1  f  1  c-t  1  ona  »esg  1 1  lna_.1_t t-be 

task  was  not  performed* 


STEERING  COMMITTEE  ACTION) 


Indicate  one  of  six  cateaorlesi  D1 saoorove/No  Action/  or  Cancel)  Imple- 

_ men E meroencYl  Implement  Priority) _ Imolem-nf  Routine!  end  Implementation 

Studv/or  Feasibility  Study)  and  Table* 


confVcmar’tfr  .SC  -----  II 


252 


GUIDELINES  FOR  Task  RESOURCES  ALLOCATION  and  SCHEDULE  FORM 


1.  SCOR£l _ 


Th(a  ripeuwfnt  «tt»hUiK»«  the_ra.aui  ramanl  tor  jim*  -i a  the  Taak - 

Reaouree  All  fleet ion .  and-  Schedule  (which  util  he .rate  read - 


i 


JS  Jl  !ll> 


to  the  aoftwar#  or  hardware  wit  hi  g.  the  Mil  Avionica  Integration _ 

So.?..* FaCiHtv  (AISFi.  Thit  f«f«i  will  pp«vide  aeheduHpO  and  _ 


dement  data  a"d  ia  ueed.to  supplement  the  Talk  RaOueat. _ Ihil 


ai*rLa“  — 
lorm 


c  ap  be  utlllitd  hv  etvj'UAi  military  or_  eont  rac  t  on  personne  1 .  _ _ 

2.  APPLICATJOjil _ _ _ _ - . 

_  ConHquraHon  Management  ICM)  ..re.Qu.free  tr<s  form  a»  a  vehicle  fa) _ 

to  provide  i  Mormat  i  on  for  the  Steering  Committee  (SC>»  th)  to  L_er.e>f<Jfl 
_  th.f  i  nf  ormat  f  on  required  tor  CM  to  prepare  the  Agenda  and  to  keep  . 

_ the  atetus  1q9b  required  by  the  Steering  Committee,  and  (c)  tn  control 

changes  to  the  aottwere  tor  hardware)*  thu»  assuring  that  the  con* 
figuration  ia  aeeuratelv  refleeted  in  the  documents* i on.  _ 

J«  RESPONSIBILITIES  OF  the  QRISlNATORt _ ... 

A,  Th*  Ta»k_ Schedule  wOJ  be  prepared  hy  the  design  .engineer 

delegated  this  reaponai H 1 i tv  bv  Ma  group  leader. _  _ 

8  ,  The  Task  Schedule  must  be  fjJHpd  out  and  submitted  to  CM  prior _ 

to  the  next  SC  meeting  which  will  Jtorma J M_y_  be.  ..live  working  rlayS 
a  *  t  r  r  the  Te»*  Request  hat  been  approved  bv  SC  .tor, implemente" 


t  i  on. 


C.  cm  RESPONSIBILITIES:' 

A,  Log-in  and  a»aion  a  eontroi  nu»h«i>  tor  the  Teak  Schedule.  (Note: 
this  number  w(ll  he  the  9ame  as  the  number  on  the  Teak  Reoueat 
i n i t i at i ng  the  teak,) 
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H,  a.-m  t  he  Task  Schedule  to  thp  St  ee  r  t  na  Committee  ade^dm  a  no 
forward  thf  Task  Schedule,  Task  feauest,  »nd  "  reoui  re»e»t  s " 
docu irant  to  tt>e  Steerina  committee  # or  action, 

C  •  l  *  approved  bv  the  S  t  ee  r i nq  Committee,  fotxard  tta  Task  Schedule, 
Task  Peduest  and  M  reou  (  ra*en  t  s 11  docunant  to  the  responsible 
arour  leader, 

0*  Develop  the  Slerrfnn  Committee  minutes  shextna  actions  taken, 
a  n  d  distribute  to  a' I  q  r  o  u  P  1  e  a  d  r  e  s  so  tnev  *av  inform  those 
individuals  within  their  respective  qrouos  whose  tasks  have  been 
reviewed  hy  the  Steerina  Committee  «hat  action  was  taken, 

E«  furnish  Periodic  reports  to  the  Steering  Committee  vo'datlng 
delinquent  Task  Schedule  lists, 

s,  PRrPA«ATioNi  OP  mi  SChFDMlT*  See  Ta$K  pfSODPCFS  aL  LDC  a  T  mu~7hn  ~~ 
SfHf  l'"LE  P0«M  and  r.'STRt'cTinNS  FOB  p  r7p  a£  i  N  q  TaSK  ~HESnUiicr  S  ALLOC  A  C  T  Om 
AMD  SCHEDULE,  . 
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Task  KFSOIIRCFS  ALLOC  AT  T  0  ►'  AND  SCHEDULE  F  (IBM 

TlTCFt  CCL  NO.J 


PfKSON  ASSIGNED  TASKj 

date  of  supmittalj 

•  •• 

RESOURCES  P  E  0  it  I  RE~D  To  R  TA$K| 
ha»('Kape  RFQHiPfr, 

•  3»  •  ••  .•_»  ««m  mmmmm  mm  m  9  m  mmrnrnm  mm  m  m_mM  «■#■«**• 


- . -  ..._ _  _ CURREH1 _ _  L _ CHANGE 

E s T i M a f i w NuMRF fT  OF  h'apoVaRE  HOyRSl  ...............  / 

FSTIuATE0  NUMRER  OF  MANHOURS t  ...............  /  ......... 

F  S T  I  ma'T E  0  WORK  START  ruftT  ...............  7  ---.-.--- 

rsTl«ATED  COMPLETION  DATE!  _  _  ...............  /  ......... 

REMARKS/REASON  FOR  change i _ 


************************ DO  NOT  WHITE  PEI Ow  THIS  LINE*** 
STEFRING  COMMITTCF  ACTIOnT  ‘  '  ~~  oaTei 


COMMENTS! 
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TASK  RESOURCES  ALLOCATION  AND  SCHEDULF  FORM 

INSTRUCTIONS  Vor’ PREPARING- TASK  RESOURCES  ALLOCATION  and  SCHEDULE 


_ Person  assigned  the  task  <3  redulred  to  complete  »«ch  blank,  either 

In  Ink  o'*  type  except  as  stated.  Do  not  write  below  the  line  of  *'s. 


TITLE! 

The  same  title  that  was  used  for  the  Task  Request. 


CCL._N.Q-l- 


W.*_ - 

The  se<"e  number  that  was  assigned  to  the  Task  Reauest,  this  Is  a  Task 
and  will  be  u*ed_tfi.  cP.O.rdl n^-te  the.  TaS-k.  Reaueat-.Al.t.h-.t.h^-TaS.K  .Sghej<u1 « 


PERSON  ASSIGNED  TASK!-  ... _ 

Name  of  the  person  assigned  the  task  bv  the  Group  Leader, 


DATE  OF  SU8M I TTAL  I 

The  actual  date  tha_t  the  form  I  a  -Submitted,  to  configuration  Management 
fCN), 


HARDWARE  REQUIRED! 

ThI  s_l,I  sts__the^yge.  end  _de*chlpt  lj.o...of_hjrjiware-iifiJ.dadr  e.  Q, t_  Intef.dat.ai- 
Ha  r r  t  S »  O-DTS,  F/FR-nTS,  ITf,  360/65,  «-Pl,  MDS  or  AGERDl  CABLING  and/op 
SPECIAL  EQUIPMENT,  _ 


.stimated  numbfr  OF  hardware  hours i  _ , _  _ 

This  entry  Was  two  Daftsi  the  first  part  Is  for  the  current  estimated 

number  of  h,rqw,re  hours  needed  for  the  t»sk  and  the  second  Part  Is  » 

Revised  estimate  of  the  current  estimated  number  of  hardware  hours 
needed,  .  _  .  _  .  _ _ _ _ _  _ 

ESTIMATED  NljMRfcR  nr  MANHOlJRSl  _ _  _  _ _ _ _ 

This  entry  has  two  Pa  r t  s  j  the  first  o*r  t  (s  for  the  current  estimated 

number  a*  manhour»  needed  for  the  task  and  the  Second  Pa" t  Is  a  revised 

estimate  of  the  current  estimated  number  of  manhours  needed, 

estimated  work  start  DATE t 

This  entry  ha*  t»s  (ijrtl)  the  f  1  r  St  P8rt  I  8 f  or  t  he_cur  rent__eSt  I  "at  ed 
flrat  day  of  work  for  the  task  and  the  secnng  part  Is  a  revised  estimate 
of  the  first  dav  of _ work  for  the  task, _ 


ESTIMATED  COMPLETION  DATEj  _  _ _ 

This  entry  has  two  Pattsj  the  first  cart  Is  for  the  current  estimated 
date  t h , t  the  work  will  be  completed  and  the  second  Pant  Is  a  revised 
estimate  of  the  date  that  the  work  will  be  completed. 


REmar«s/REason  eqR  ChangEi 

This  entry  has  two  Parttf  the  first  narf_Is  anv_st_et?.,,’*nT  C » 3  that  the 
person  assigned  the  te»y  wishes  to  »«itt  concerning  the  t»sk,  tKe  second 
Part  Is  the  reasonfsl  for  submitting  a  change  to  the  Task  Schedule, 


uTEERlNG  committee  action,  _ _ _  _ 

Fnter  "APPROVED"  or  "DISAPPROVED"  denendlnnon  the_ect!on  taken  by  the 
Steerinq  Committee, 
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G'iltJ'ELlNt'S  FOR  TASK  r|_rS,|RI-:  Pt>RM 


1  .  SCOPE  _  _ _ _ _ _ _ _ _ _ _ 

T  k  i  a  document  establishes  the_.reaui  reRert .  .tor.  iise  _of  the..  .  . 

T«»K  Closure  tor's  when  m8kin<j  c  h  a  p_g®4  to  the  software  or 

haPdware  hit  hjn  the  F«lll  AyJ  on  i  ca_  lPteP-Rja_lxn.--&Olt.*'Arj»__Fac  i  1  i  t  v_ _ 

(AISF1.  This  for"  will  prov  1  de  x  I  0*  i  no.  in# erRat  i  0_n  .nece$SaP.Y  foP 
conf  i  nurat  i  on  control  and  san»aeaent.  dat*_afli.U  uaed_io_AuoP]  ement 

form  can  ne  utilised  by  clY.iHa.0t  m.i  J  i  t.ar  y  ar.tflntnactor  i'frsonne!  •» 
2,  application:  .  _ _ _ . _  _  _ _ _  .. 

Con  f  i  go  r  a  t  j  on  Management  (CM1  requi  r»9 . this  form  as. a  AtAhlt-Lft- LaJL _ 

to  provide  i nf ormet i on  _f or  the  Steering  Committee  (SCH  (hi  to _ 

provide  The  information  required  for  C M  to  keep  the  status  lone 
reoyired  »he  Steering  Committee,  and  Cc)  to  control  change*  to 
the  9oftware  (or  hardwareTf_  t  h  US  a?  r  f  ng  th.at_jKj.ft  ton  f_f  a.U  Pat  i  cn 

is  aecutataW  reflected  i  n  _t  he  documentation,  _ _ 

J,  PrSPONSIBTL TTTEF  n?  t*E  QPIGINArQdl _ 

a.  The  Task  rlosure  will  be  prepared  by  the  design  engineer 

delegated  this  resoons  i  n  i  1  i  ty^  bv_  M_? _ opoup  leader. . . 

H ,  The  Task  Closure  will  be  submitted  to  CM  after  all  documentatj on 
has  bee"  comol eted  and  the  task  originator  has  verified  the  task 
meets  the  reaul  ren»n[s  oith(  Task  F.e.aues.t  _and  has  _coo_rdi  "eted 
the  T#*k  Cl o»ure  form.  If  the  task  affects  computer  opePatlonSt 
the  Operations  manage"  must  elso  coordinate  the  Task  Closure 

form,  _ _ .  .  .  _ _ _ _ _ .. 

a,  CM  pESP0NS  I R 1 1  I.TlFSj _ _ 

A,  Loq“  ( "  and  a*8id.n  #  control  "umber  fgr  t(^j»  TftSk  Closure, 
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(Kiotej  This  nu*b*p  w 4 1  1  he  the  s  » t>  e  as  the  n u m o e r  on  the  Task 
Request^  Initiating  the  talk).  _ 

B.  Verify  the  noiUitentat  f  qtl  teeta  *1.01*0*!  .standards  arm  create  a 

. . c onfl gjjj.ed-da8eV.lha- of  the  soil “are  agorae  or  veri  f y -to  a— tar-do. 

“are  ehanae.*  -  If  .  the  .at  anda-fda. .  are-~not  iret#-.  tha  task  Closur# 

til1  not  fee.  accepted. _  .. _ _  _ _  _ 

_ C  • _ Dlstrlhute  the  applicable  dor  unentat  i  o.n  Ci.e..  -  users1  guide) 

to  the  appropriate.  Locatl one. _ _  _ _ _ _  _  _ _ 

H,  Initiate  action  necessary  for  loading  any  new  or  modified 

_  _  software  Into  the  ca*outer. . . . . 

5,  PREPARATION  OP  TASK  Ct.OSUREl _ _ _ _ 

See  TA5K  CLOSURE PpRM  _a.nct  INSTRUCTIONS  FOR  PREP  AH  I  MG  TASK  CLOSURE. 


CCl  NO, I 


Task  CLOSURE  form 
TITLE! 


0 ATE  of  SUnMITTALi _ _ _ _ _ _ _ _ _ _ _ _ _ _ 

ACTUAL  HArPWArE  MOIIPSI  ACTUAL  MANHOURS! 

_ _ -  -  -  -  ».  - . . . mAlMUMBMUM 

OOCUwENTATION|  if  .yes  X. WHERE 21 _ _ - _ 

IF  NO  (WHY?1 

APPLICABLE  FTLFCSU _ _ NAME1S1 _ L. _ JJ1C AJiO NESi _ 


./.  -W..M  T- 8,«|l.»i  »«»-- -  *-• 


/ 


Change  DESCRIPTION  A_up  ijS.E.e.  imp  ACT  I. 


Originator  ACCEPTANCE  coordination  and  PATE! 

OPERATION  COORDINATION  and  DATEj 

m 
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NOT  write  BFLO*  this  line< 


Cm  MANAGER! 


CM  CLOSE  0  A  TF | 


COMMENTS! 


********** ****4 


1 


task  closure  form 


PREPARATION  INSTRUCTIONS  FOR  TASK  CLOSURE  FORM 


The  Paraon  a&a±aQAri  -the  task  is  required  to  rompiete  »»rh  hlank  in  ink 
op  typed*  except  at  stated.  Oo  not  write  be'ow  the  M"«  of  *'s. 


TIIL£l _ _ 

The  a a»e  title  that  was  used  for  the  Task  Request  is  required. 


CCL  NO. t 

The  aa'"e  number  that  waa  assigned  to  the  Task  Request,  thia  task  id 
_  WUI  be  used  to  coordinate  the  Task  Request  with  the  Task  Closure. _ _ 

PA  !£..  Q£_. .  S  UB-N.I  I  -IA.H _ 

The  actual  date  that  the  form  4a  submitted  to  conf  4  gurat  4  on  Manaqement 

DOCUMENT  A  T  ION  t _ _ _ 

The  "vea"  blank  4a  to  he  comoteted  4f  document  at  4  on  exists  with  an  explana- 

_ t  i a"  aa  to  where  the  documentar 4  on  can  be  located.  The  "nn"  blank  4«  m 

be  completed  H  no  doeumentat ion  exists  with  a  brief  explanation  as  to 
whv  there  i  S_  n. o  d o c  u m e n  t  a M_on . .  _ . . . . . . 

■-PLICARLE  FJlE.rs).!  _  _ _ _ _ _ _ 

Any  file*  affected  due  to  the  Task  Reauest  change  will  pe  listed  along 
_ with  their  locati  ons. _ _ _ _ 

CHANGE  DESCRIPTION  ANO  USER  JNRACTj  _ _ _ 

A  description  of  the  changes  implemented  and  thefr  impact  cn  the  user/ 
operator  1»  to  be..  littecL  hefe* _ _ 

originator  acceptance  coordination  anq  PATEi _ 

The  originator  of  the  Task  Reguest  shall  sign  and  date  the  Task  C'osure 
Eorr  indicating  that  the  *sfk»eeti  with _ his  snee i f i ea* i ons. 

OPERATION  COORDINAT  ION  jAND  DATE  t 

Operations  coordinate*  and  dates  the  Task  Closure  Form  jf  the  closea 
Task  Request  affects  Operations, 


CM  maNaGERj 

Cm  coordinates  when  the  Task  Reouest  is  closed  and  e'l  documentation  is 
tunned  in,  _ _ _ _ _ _ _ 


cM  close  datei  _  __ 

Enter  the  date  CM  closes  the  Task  Reoyest, 
vi)MMf  NTS  j  _  _ _ 


Any  statements  made  by  the  Steering  Committee  or  CJA  that  are  anolicah'e 
are  entered  here. 
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PREDICTIVE  SOFTWARE  COST  MODEL 

MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES  (Cont) _ DATE:  28 

STRUCTURED  DESIGN?  -  DESCRIBE 

No 

STRUCTURED  PROGRAMMING?  -  DESCRIBE 
No 

CODING  GUIDELINES: 

Experience  of  simulation  programmers. 

CHANGE  ENTRY  METHOOS: 

CRT  on-line 


SCHEDULE: 

Informal 

REPORTING: 

Task  Listing  -  see  p.  D-29 

COMMENTS: 
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PREDICTIVE  SOFTWARE  COST  MODEL 

MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES  (Cont) _ DATE:  28  Sept  1979 
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PREDICTIVE  SOFTWARE  COST  MOOEL 


CONTINUATION  SHEET _ DATE:  28  Sept  1979 


5.  DESIRED  OPERATION: 


Describe  the  characteristics  of  computer  operation  or  use  desired  as  a 
result  of  this  change,  using  the  same  guidelines  as  under  "Present 
Operation. " 


6.  REASON  FOR  CHANGE: 

Present  the  rationale  behind  the  need  for  this  change,  emphasizing  the 
relative  importance  of  the  current  problem  and  the  desired  result. 

7.  CHANGE  HISTORY /RELATED  CHANGES: 

Information  to  be  supplied  by  Sacramento  ALC 

8.  REQUESTED  BY: 

Person  to  be  contacted  for 
further  information. 

9.  REQUESTING  AGENCY:  COORDINATION 

Wing  coordination 

Name  Orgn  Phone 

Name  Phone 

10.  REQUESTING  COMMAND:  APPROVAL 

SAC/TAC/USAFE 

11.  SUPPORTING  AGENCY:  APPROVAL 

SM/ALC 

Name  Phone 

Name  Phone 
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PREDICTIVE  SOFTWARE  COST  MOO  EL 


CONTINUATION  SHEET  —  Documentation  (Dot  Files) _ DATE:  28  Sept  1979 


File  Designation 

File  Content  and  Structure 

axxx 

File  series  name:  a  indicates  aircraft  series; 
xxx  is  change  number. 

axxx.P 

CHANGE  STATEMENT  —  File  is  for  insertion  of  a  change 
statement. 

TITLE: 

CHANGE  REQUIREMENT: 

CURRENT  MECHANIZATION: 

OBJECTIVE: 

NOTES : 

STATUS : 

axxx.M 

MECHANIZATION  —  A  narrative  which  is  source  data  for 
update.  Note  if  change  as  mechanized  is  different  from 
requirement . 

DATE  OF  LAST  UPDATE: 

DESCRIPTION : 

axxx.K 

KEYINS  —  For  generating  addendum  tapes.  Machine  language 
code  for  patches  entered  prior  to  executing  a  compiled 

OFP.  Assembly  language  statements  are  not  required  but 
provide  design  interpretation  of  ML  code.  Note  required 
General  Navigation  Computer  and  Weapons  Delivery  Computer 
cues . 

$GNC  -  KEYINS 

LOC  IS  WAS  CORRESPONDING  AL  CODE 

(address)  (revised  (old 

ML  code)  ML  code) 

SEND 

SWDC  -  KEYINS 

LOC  IS  WAS  AL  CODE 

SEND 

axxx.R 

REASSEMBLY  —  Similar  to  KEYIN,  but  used  to  reassemble  a 
program. 

SGNC  -  REASSEMBLY 

(Exact  card  image,  punched  cards  format  previously  used 
for  reassembly) 

SEND 

266' 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  —  Documentation  (Dot  Files) 


DATE:  28  Sept  1979 


File  Designation 


axxx. 1 


File  Content  and  Structure 


axxx. F 


axxx.G 


TEST  PROCEDURES  —  Step-by-step  test  procedure  to  checkout 
a  change. 

FLIGHT  TEST  REQUIREMENTS  —  Contains  information  for  flight 
test  of  OFP  change.  Contains  summary  of  change  and 
requirements  for  test  execution  (digital  channels,  test 
parameters,  success  criteria,  et.al.). 

GLOSSARY  —  List  of  any  new  labels  or  mnemonics. 


1  TITLE  PACE 

2  INDEX 

5  DOCUMENTATION  STANDARD  FOR  PROGRAMS 

DOCUMENTATION  STANDARD  FOR  SUBROUTINES 
5  DOCUMENTATION  STANDARD  FOR  LIBRARY  SUBROUTINES 

EXAMPLE  OF  PROGRAM  DOCUMENTATION 


9  EXAMPLE  Of  SUBROUTINE  DOCUMENTATION 

1 o  EXAMPLE  OP  LIBPARY  SUBROUTINE  DOCUMENTATION 

Ta  USER'S  GUIDE  PROCEDURES 

"is  7x AMPLE  OF  USER'S  GUIdT 

1 9  FEASIBILITY  study  procedures 


example  of  feasibility  study 
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CONFiOOCGUlDE.MAN 


documentation  stanoard  i 


PROGRAMS 


■i 


-CM  J.ITlE _ I _ TITLE  OE  , -PROGRAM _ 

CM 

cm  date  of -Ias'Lchan&Li _ 

CM 

._C?.  _P^OiP>Ml!£R _ j _ 

CM 

-CF-QP.LANA.TI0N _ I _ state  what  the  program  pops, _ 

CP 

_CF  Overview  _ «  OUTLtNr  THF  LOG  I  f.  structure, _ 

CP 

— CE— Vl*?I  ABLES _ 4 SEPARATELY  DEFINE  EACH  VAPTABLE  WHOSE_NAMf  DOES 

CP  NOT  ADEQUATELY  DESCRIBE  ITS  FUNCTION,  TYPE,  OR 

_ C£ _ usage. _ 

CP 

_C L_£ X TE RN A L $ _ I _ LlS.T.  .ALL.£X,T£RNAL  .S.UBR.OL'T.1  NE S,  F  UN  C LLCMS— AND _ 

Cl  DATA  PILES  ACCESSED  BY  THE  program  and  THEIR 

-XI _ LOCATION. _ 

Cl 

— CI-gE*A*«S _ i  INSERT  comments  TO  DESCRIBE  DATA  STRUCTURES  ANp 

ci  unusual  programming  techniques  and  requirements. 

. £  I  _  _  .  _ _ _ THESE  COMMENTS  SHOULD  rONTAlM  ANY  INFORMATION _ 

r-  NETESSARY  TO  UNDERSTAND  the  program. 


CO  USER'S  GUIDE  j  A  USER'S  GUIDE  IN  THE  SOURCE  LISTING  is 

JCO _ optional. _ 


NOTE  I  OEScRIPTIVF  COMMENTS  should  re  GENEROUSLY  USED  THROUGHOUT  The 
_ S 0_UR C E _c 00 f _1 0_p E SCRIBE  WhaT  IS  HAPPENING. _ 


OTHER  DOCUMENTATION  NEEDEDl 

SOURCE  LISTING,  either  bobo“  unassembled 

_  _ _ USX?  '  S_GUJ  DE _ 

location  OF  JORSTRE *m$/CSS  FILES  0»  MACROS 
_ ASSOCTaTED  NITH  the  PROGRAM _ 


CONPiDOCGUIDE.man 
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3 


documentation  standard  2 
subroutines 


— cm  title 

_ 1 _ 

TITLE  OF  SUBROUTINE _ 

CH 

—  ch  date  of  last  change.* 

C" 

CM  PROGRAMMER 

—  _» 

CM 

_CF,_txi»LANmoN 

1 

5TATE  WHAT  THE  SUBROUTINE  DOFS. 

CF 

cr  parameters 

t 

DEFINE  VARIABLES  WHICH  ARF  PaSSFD  TO  AND  FROM 

cf 

CF _ 

THE  SUBROUTINE, 

Cl  EXTERNALS 

Cl  _ 

1 

LIST  ALL  external  SUBROUTINES,  FUNCTIONS  AND 
data  FILES  ACCESSED  BY  THF  SUBROUTINE  OR  which 

Cl 

Cl 

call  this  subroutine. 

Cl  Reharks 

_£i _ 

1 

INSERT  COMMENTS  to  DESCRIBE  DATA  STRUCTURES  ANn 
UNUSUAL  PROGRAMMING  TFTHNTDUfS  AND  REOUIRFMFNTS. 

Cl 

..  ... 

thesf  comments  should  contain  any  information 

NECESSARY  TO  UNDERSTAND  Thf  SUBRDUTTNF. 

NOTE  1  DESCRIPTIVE 
SOURCE  CODE 

COMMENTS  SHOULD  be  GFNEROUSLV  used  THROUGHOUT  the 

To  DESCRIBE  MHAT  IS  HAPPENING. 

i 


3  ' 

b 

| 


1 

! 

i 

1 


OTHER  DOCUMENTATION  NEEDED  I 


! 


SOURCE  LISTING 
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4 


documentation  standard  3 


LIBRARY  ROUTINES 


£m.xjl*IE  OF.  iJk S t_CMAN££.j _ 

CM 


CM 

A  N  A  T  T  flN 


cr 

_CE_Q¥IRV1E« _ 

CF 

-_J CF_Pa»A-mU£RS_. 
CF 
* 


Cl  EXTERNALS 

—XI _ 

_  RfMA«K5  _ 

Cl 


THE  ROUTINE. 


»  LIST  ALL  EXTERNAL  SUBROUTINES,  FUNCTIONS  AND 

DATA  FILES  ACCESSED  BY  the  LIBRARY  ROUTINE. _ 

J _ INSERT  COMMENTS  TO  DESrHlBE  DATA  STRUCTURES  ANft 

UNUSUAL  PROGRAMMING  TECHNIOUES  and  REOUIPENENTS. 

N  _ 


NECESSARY  TO  UNDERSTAND  the  LIBRARY  routine. 


CO  USER’S  GUIDE 


a  user's  guide  in  the  source  listing  is  optional. 


NOTEi  DESCRIPTIVE  comments  should  BE  GFNFR0U5LY  used  throughout  The 
_ SOURCE _C ode  to. describe  t _ I  s  HAPPE NING. _ 


OTHER  DOCUMENTATION  NEEDED! 


SOURCE  LISTING 

_ _ USER’S  GUIDE  _ 


boiler  plates  for  the  standards  are  contained  in  tme  following  locations! 


INTERDATai  STSTiOOCSTD.FRM/S 

_ HARRIS! _ BYSTtpOCSTD _ _ _ 

RECORD  NUMBER!  PROGRAM  S-QSt  SUBROUTINE  50*B0|  LIBRARY  ROUTINE  85*125 
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CONFiDOCCUIDE.MAN 


EXAMPLE*  PROGRAM  DOCUMENTATION 


then  EUMINaTEAREAj 
ENPt _ _ _ 


cr 

I  Variables 


ci 


CI 

_CJ _ 

CI 

XTERNA 


CI 

__CI _ REMARKS 

CI 

__fl _ 

CI 


i  parlst  is  the  parameter  list  and  buffer  area  for 


SOASAVE 

elist  is  the  parameter  list  for  the  system _ 

eliminate  routine 


the  PR QCRaM  is  COMPILED  AS  A  FORTRAN  PROGRAM  FOR 
'  EASE  OF  I/O,  '  '  " 

DUE  T 0  THE  INTERNAL  OPERATION  OF  VULCAN,  THI S _ 

PR'OGRam  MUST  be  run  as  * ACUT IL  in  ORDER  to 
utilize  thf  system  routine  sdasave*  in  o»der 


TO  EFFECT  this  the  program  should  BE  EXECUTED 

job  STREAM  FILE  WHICH  RENAMES  ACUTIL  TO 


TEMP#  PACKPURGE  to  ACUTIL#  EXECUTES  ACUTIL 

_ A ND  UPON  CQMPLET ION  RENAMFS  ACUTIL  TO 

P'ACKPURGE#  TEMP  TO  ACUTIL, 


—  jse _ 

OLTfST  BLOK  1 

_P*»LST  BLOK  l<i _ 

RUST  810*  1 

_ £L1AI__BL0k_J _ 

ARCNT  BLOK  l 

THA _ JPACK _ 

TAM  PARLSTfO 

.TLO  i^ARLSl _ 

BLJ  SDASAVE  FIRST  CALL  TO  DASAVE 

_ _ DATA _ 1 _ FUNC-IION  CODE— Ill— GET  All.  AREAS 


—  - 

BP? 
T£m 
BLU 
.  SOE 
TEM 

Rl  .1 

DONE 

A  P  C  N  J 

NO  AREAS  EXIT 

NUMRFR  OF  ARf  a  RLOfKS  RpT'IRNFO  *  2D  WOROS/BI  Dp* 

$T1ME 

7 

GET  TOOAYS  DATE 

SUBTRACT  7  DAYS 

POATE 

r.TiRpi 

INITIALIZE  PURGE  DATE 

SFT  K  RFP.TSTFR  TO  aRFa  HI  OrK 

eoz 

done" 

NO  MORE  AREAS  TO  PROCESS 

tj  K 

CHECK  IF  DATA  FTLF  OR  PROGRAM  FILE 

BON 

MLOOP 

PROGRAM  FILE  GET  NEXT  AREA  BLOCK 

BLJ 

gltest 

CHECK  IF  OOOOSYST  OUaLIFIfR 

BNZ 

MLOOP 

res,  get  next  area  block 

BLJ 

■  Hill* 

CHECK  last  access 

BPN 

BITHIN  7  DAYS  GET  NEXT  AREA  BLOCK 

BLJ 

ELIU 

TO  LONG  ELIMINATE  IT 

• 

Bl'C 

MLOOP 

GET  NEXT  AREA  BLOCK 

* 

GETAREA  ROUTINE 

* 

t:::tz:s:c:sser 

* 

ft 

ON 

ENTRY  TO  This  ROUTINE  loc  arcnt  contains  CURRENT  buffer 

ft 

POINTER. 

ft 

SUBTRACT  20 

f  ARE  ABL  OCK  SIZE!.  ....  _  . 

• 

T  F 

NOT  POSITIVE  DACALL  ELSE  MOVE  POINTER  Tp  K  REGISTER  A  RETURN. 

* 

DACALL! 

# 

CALLS  SDASAVE, 

ft 

TRANSTFRS  ruffer  count  to  areacount. 

ft 

RfTURNS  to  mainline  IF  nothing  in  BUFFFR  I.E  done. 

ft 

fl.se 

RE-ENTERS  GFTAREA. 

ft 

ft 

ft 

GET  ARE  A 

AO* 

-2V  .  . 

move  POINTER  TO  NEXT  AREA  DATA  IN  BUFFER 

OAC 

ARCNT 

ADDRESS  OF  LOCATION  TO  ADD  TP 

BNP 

DACALL 

buffer  completely  prpcfssed  get  ne*t  buffer 

TMK 

ARCNT 

MOVE  POINTER  TO  K  REGISTfR 

BUC 

0.  J 

RFTURN  TO  maINLInf 

DACALL 

tlo 

PA»LST 

GET  ADDRESS  OF  PARAMETER  LIST 

BLJ 

SDASAVE 

CALL  SYSTEM  ROUTINF 

data 

0 

NOT  THF  FIRST  CALL  SP  0  MERE 

BN? 

SflO 

problems  send  error  message 

TE* 

ARCNT 

MOVE  BUFFER  SIZE  TO  ARCNT 

BOZ 

BUCOJ 

ALL  DONF  RETURN  KITH  2FRP  FLAG  SET 

BUC 

GTAREA 

GO  SET  POINTER 
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CONFiOOCCUIDE.H*N 


NaM 


ELIMINATES  file 

^R£7UfLNS  _  TQ_HA  X  hl_ 


IMD  o,K 
Tn 


TMD  8,“ 

BN7  S<ll 
C _ 


GET  APEANAME  FROM  BUFFER 
PUT  TN  PRAM  t 


GET  QUALIFIER  FROM  BUFFER 

PUT  IN  PRAM  LIST _ 

PROBLEM  SEND  ERROR  MESSAGE 


ACCESS  ROUTINE 

_ «  sp  a  s ****  Miit  _ 

GETS  LAST  ACCESS  DATE  AND  PURGE  DATE. 
SUBTRACTS  PURGE  DATE  FROM  ACCESS  DATE 
_RE TURNS.  _ 


» 

ACCESS  ~  T>E  17, K  GET~  LAST  "ACCESS  DATE 

_ THa  OTTME _ GET  PURGE  DATE _ 

SAE  SUBTRACT 

BUCOJ _ gUC  0,  J_ _ _ 

I  E  ND 

C 

c 

C _ THE  following  DISPLAYS  fRRQR  MESSAGE  FOR  SqaSaVE  ERROR 

c 

c  _ _ _ 

«0  WRITE CJ.flOO) 

*00  FORmaTC  ERROR  IN  SdaSaVE  ROUTINE  CONTACT  PROGRAMMER") 

C'  GO  to  50 


C  the  FOLLOWING  DISPLAYS  ERROR  MESSAGE  FOR  SELIM  ERROR 

C  . .  '  “  “  ■'  '  "  "■  '  . 

*1  _WPITE{J,«lu) _ _ 

*P  FORMAT ( »  ERROR  IN  SELIMJNAtE  ROUTINE  CONTACT  PROGRAMMER") 


COMMON  EXIT  LOGIC 

C  So  REWIND  IP  '  " 

r  Si  P£AD(' 0,500) VARIABLE  LIST 

IF (FOR )G0  TO  60 

C  ■•ITf (6,50?) VARIABLE  LIST 

'  GO  To  5i  '  ■  -  “  ~ 

'  # ?  ri  r>5r  t  t 

t*'  ' 

—  C0W>tD0CCUXDl“.MAN  i*—  .  e 


EXAMPLE |  SUBROUTINE  DOCUMENTATION 


SUBROUTINE  GTPATECTEMP) 

CM - 

CM  TITLE  J  GTDATE 

CM. _ 

cm  d*te  or  last  changei  b  nov  78 


C  M  _ _ 


cm  programmer 

PM 

1 

M, TAYLOR  (  J.CIAAR 

PEVTSION  1  .  N.  TFAGUF _ 

CM 

CF  explanation 

I  THIS  subroutine  converts  a 

N  ALPLHARFTir  MONTH 

CF 

CF 

NAmE  TO  A  NUMERIC  value, 
AOOFP  TO  ThF  patf  TO  Al  l  PH 

thirteen  DAYS  are 

FOR  THFCKING  FOR 

CF 

TF 

delinquent  task  requests. 
NEXT  MONTH  AND/OR  YFAR  TS 

CROSS-OVER  TO  The 

TAKEN  INTO  ACCOUNT. _ 

CF 

ci  parameteps 

i 

TFMP  .  ALPHANUMERIC  INPUT/OUTPUT  OF  DATE, _ 

Cl 

C-L 

FORMAT  I 

cr  externals 
ci _ 

> 

CALLED  8 V  MAIN 

1 QCATED  IN  TRTSMAIN _ 

Cl 

-T  REMARKS  ...  _ I  PATES  will  NOT  be  CQNVFRTFO  beyond  TME  year  1909 


Cl  — _ 

C  DATA  DEFINITION 

_ INTEGER  TEMPt35.YDATE(12,25 _ 

COMMON  /IPATE/YDATE 

C  END  data  DEFINTTON _ _ _ 

c  get  numeric  date  FOR  Test  in  CALLING  ROUTINE 

DO  10  1*1, J2  _ 

if(Temp(2).eo,yoate(I, m  go  to  20 

10 _ C  ON  TINUE _ 

WRITEI3. 10y0)  TEMP(2) 

iooo  formatcq  month  given  cap,1)  is  wrong  ending  session') 

call  exit  "  ' 

C  SET  alpha,  month  TO  NUMERIC  month _ 

20  TEMPI  2) «i 

z _ ADD  IN  13  FOR  Two  meek  CHECK  _ 

TEMP  ( 1  )*TEMP(1)M3 

C  CHECK  TO  SEE  IF  IT  is  INTO  ANOTHER  MONTH _ 

ir(TEMPfi).LE,Y0ATECI#2>)  GO  TO  9999 

C  _YES  SUBTRACT  OUT  FOR  DAYS  INTO  NE*  MONTH _ 

TEMP(n«TEMP(n-YDATE(I,2) 

JC _ INCREMENT  month  COUNTER _ _ _ 

TEMPI 2)*TEMP(2>*1 

C  CHECK  TO  SEE  IF  INTO  NEW  YEAR _ 

IF(TE“P~(2)  ,LE,  125  GO  TO  9R9R 

ADO_  TO  YEAR  COUNTER  IHILL  NOT  WORK  FROM  1999  TO  20005 _ 

*  TEMP (35* TEMP (3) »1 

ENO  nr  DATE  ROUTINE _ _ _ 

RETURN 

ENO _ _ _ _ _ _ 


276 


CONFiDOCCUIDE.MAN 


.  _  CH  ENm_PQIiiT3 _ | _ JULBIN 


CM  LIBRARY.  NjlM£ _ | _ DE.PL.1  B 


CM 

date  op  last 

CHANGE i 

A  MAT  77 .  . 

CM 

CM 

programmer 

! 

KARL  w  RASS  . 

CM 

CP 

explanation 

1 

the  buffer  starting  AT  IRUPP  AND  FOR  NCHaR  RVTfS  long 

CP 

CP 

is  scanned  looking  for  a  valid  date  and  time  in  ascii. 

the  DAtF_IS  CONVERTED  TO  A  BTNARY  K'nPn  AND  THE  TTMF  IS 

CP 
_  CP_ 
CP 
CP 

CONVERTED  TO  ANOTHER  BINARY  WORD,  THE  APPROPRIATE 
status  is  returned.  The  datf  can  be  FTTHER  IN  INTFRDAT 

(E  ,G,  24/01/77)  OR  CONVENTIONAL  t2«  JaN  77)  OR  JULIAN 
177.0241.  TIME  TS  in  HHIMHJSS  AND  IP  NONE  IS  GIVEN 

CP 

CP 

THEN  1 2 1  00 1 00  IS  ASSUMED. 

CP 

CP 

overview 

f 

SCAN  THE  BUFFER 

IF  THE  FORM  IS  JULIAN 

CONVERT  THE  DATE  TO  BINARY 

CONVERT  THE  TIME  TO  RlNARY 

CP 

CF 

return 

IF  ThE  form  is  dd/mm/yv  OR  DD/m«m/YY 

CP 

CP 

IP  the  year  IS  LEAP  VEAR 

IP  THE  MONTH  IS  LATFR  Than  fer. 

CP 

CP 

ADD  1  DAY  TO  TOTAL  DAYS  IN  DATE 

CONVERT  DATE  TO  BINARY 

CP 

CP 

convfrt  time  TO  binary 

RETURN 

CP 

Cl 

parameters 

1 

INPUT! 

Cl 

Cl 

IBUFF  -  BUFFER  START  ADDRESS  WHERE  ™E  DaTE/ 

TIME  IS  LOCATED 

Cl 

Cl 

NCHAR  •  LENGTH  IN  BYTES  OF  JBUFF|  I«  FORmaT 

Cl 

Cl 

OUTPUT! 

IBIN  -  IBINCJ)  IS  BINARY  DATE 

Cl 

ct 

I8INC2)  IS  BINARY  TIME 

istat  -  statusi  range  -6  -  01  14  format 

Cl 

ci 

externals 

« 

CALLS  FSCAN,  LOCATED  IN  SYSlUSER  LIBRARY 

Cl 

CI 

remarks 

1 

after  calling  julbin,  subroutine  Julian  must  be 

cl 

CI 

CALLEO  TO  CONVERT  THE  BINARY  oaTA  TO  JULIAN 

FORMAT,  LEAP  YEAR  CALCULATIONS  WILL  BE  INCORRECT 

I 

BEGINNING  WITH  LEAP  YEAR  1980, 

•PROS  JULBIN 


96 


tun  on 


MU 


SUBROUTINE  JULBlN(lBUFF, IBIN,NCHAR, ISTaT) 

C _ T_, _ , _ _ _ _ _ _ _ 


DATA  IHQNTH/'JAN  «  ^  ♦  FEB  UiHAg  « . »  APR  '. 
*  'MAY  ','JlfN  ','JUL  »*'AIIC 

.*  _ 1  SEP  '.'OCT  '.'NOV  '.'DEC  '/ 


_ DATA._IDEC/  '  _ »/,ICflLON/i  | _ U _ 

OATA  IOFLIM  /'/  '/ 

C  FI  NO  I N G  ~OUT  Tn"  Th7t  FOB  M  The"  buffer  is  IN 

c _ 

CALL  FSCANJISCINIT',NCHAR,IBUFF) 

_ CALL-FSCAN(»DLIN',1.1DEHH.IRECA) _ 

CALL  FSCANCGTOTSPMOISP) 

_ CALL  FSCANCTEXT'.ITEXT, LENGTH) _ 

C 

_ IF  THE  FORK  IS  IN  Jt'LIANf  YR.DAVl  CO  TO  70 

C 

_ IF (LENQTH  .EQ.  6)  GO  TO  70 _ 

c  _  _FORM  MUST  NO*.  BE  IN  DAY  MONTH  YR _ 

C  02  OEC  75 

_£ _ 02/12/75 _ 

CALL  FSCAN(  i  STolSP  MDISP) 

CALL  FSCAN ( ' NUMBf RJ , IOAV»NNUM,LFMGTH) _ 

IFdPAY  ,GE.  32  ,  OR .  ID  AT  .LE.  0)  GO  TO  990 

C_ .  .  _ _ 

C  IF  THE  FORM  is  IN  DO/mm/TY  (02/12/75) 

_£ _ 7 _ 

CALL  FSCAN('GTDISP',IDISP) 

CALL  FSCAN ( 'NUMBER  1  , I M0 N »  NNUM, LENGTH) _ 

IF ( I  HON  ,LT,  0)  GO  TO  2 

IFCIMON  ,EOL  0  .OR.  I  HQN  ,GT.  12)  GO  TO  99l 
I  TEXT  f 1 )  ■  IMONTH  (IMON) 

_ GO  TO  3 _ 

IF  THE  FQpm  IS  00  HMH  yy  (j8  DEC  75) _ 

CALL  FSCAN('STDISP'.IOISP) _ 

CALL  FSC  AN  ('T'EXT',  I  TEXT,  LENGTH) 

IFtLENQTH  ,  N£  ■  3)  GO  TO  991 _ _ 

3  CALL  F5CAN{'NUMBER',ITR,NNUH, LENGTH) 

IF ( I YR  . GT ,  99  .OR.  I YR  ,LT,  0  )  GO  TO  99? 
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c 

109 

DETERMINING  If  TEAR  IS  LEAP  year  _  . 

1  9  0 

c 

151 

_ M  JL  J»l*21l _ 

19? 

HEAP  a  4  »  J 

15  J 

Iff  IYR  -EG ,  II EAP1  GO  TO  %0 

ICU 

5 

CONTINUE 

155 

C 

NON-LEaP  tear  CALCULATIONS 

157 

_C 

DO  10  I  «  1,12 

159 

"  '  TTP  1 

10 

CONTINUE 

161 

GO  TO  991 

162 

20 

NDAYS  a  ITABLE'I)  ♦  I0AT 

163 

IYR  s  IYR  *(?*»16) 

_  .  IhU 

I«IN(1)  a  IYR  ♦  NDAYS 

US 

GO  TO  80 

166 

c 

167 

c 

LEAP  YEAR  CALCULATIONS 

168 

c 

169 

30 

PO  <10  I  «  1.12 

170 

If  ( ITEXT  { 1 )  ,EG.  INONTmCP)  00  TO  50 

in 

<10 

CONTINUE 

172 

GO  TO  991 

173 

50 

If  (I  .GT.  2)  IOAY  a  IDAY  >  1 . . . . . 

.  174 

NOATS  a  ITAPLE(I)  ♦  IDAY 

175 

IYR  a  IYR  *(2**161 

176 

IPINOJa  IYR  ♦  NDAYS 

177 

GO  TO  80 

178 

C 

179 

C 

If  THE  DATE  IS  IN  JULIAN  fORMAT(YR.DAY) 

iso 

C 

181 

70 

CALL  FSCAN(iSTnlSP'.IDISP) 

1 82 

CALL  F3CANC‘3TcMAR',IDEC) 

183 

CALL  f 3C AN ( • NUMBER*. IYR. NNUP, LENGTH) 

194 

If ( I YR  ,GT.  ,99  . OR ,  IYR  ,lT,  0)  GO  TO  992 

185 

call  f scan ( •NUMBER'. 10 AT, MnUM, LENGTH) 

186 

If ( I DA Y  ,GT,  368  .OR.  IOAY  ,LT,  0)  GO  TO  990 

187 

IBIN(i)  a  IYR  *  (2**16)  t  IDAY 

188 

C 

189 

c 

PICKING  UP  The  Tihe  (HR|MIM|SEC) 

1  1 

c 

191 

80 

CALL  fSC*N( *STCHaR* , ICOLON) 

19* 

CALL  f SCAN ( •nUhBER’.IHR.NNUM, LENGTH) 

163 

If(IHR.LT.  0  .OR.  IHR.GT.  2fl)  GO  TO  993 

1  9fc 

CALL  f$CAN( iNUHBE*' .HIN.NNUM. LENGTH) 

195 

If (PIN  .LT.  0  .OR.  MIN  .GT.  60)  GO  TO  99fl 

1  9  6 

CALL  #SCAN{ INUHBER', ISEC.NNUM, LENGTH) 

107 

IfdSEC  .LT.  0  .OR.  ISEC  .GT.  60)  GO  TO  995 

196 

279 


CONE »D0C0U1DE.W*N 


12 


IBINC2)  s  56000  *  I  HR  ♦  600  *  WIN  t  tO  *ISE'C 

.IS1A_L.*_0 _ 

RETURN 


DEFAULT  OF  NOON  FOR  THE  TIME 


90  IBIN(2)  s  36000*12  205 

_ _ 2at 


RETURN 

207 

c 

2ns 

c  errors  in  buffer  passed 

209 

.  c _ 

Pjn 

C  INVALID  DAY 

*  •! 

211 

c  invalid  month 

■ 

C  INVALID  YEAR 

■  -3 

C  INVALID  HR 

a  -a 

11? 

C  INVALID  MIN 

s  -5 

215 

C  INVALID  SEC 

*  «6 

C 

217 

990  ISTAT  ■  .1 

21  a 

return 

219 

991 _ 1STAX_«  -2 _ 

220 

RETURN 

221 

992  ISTAT  s  -3 

RETURN 

223 

993  IF { I HR  .EO.  • 

21  GO  TO  90 

2?a 

ISTAT  s  * U 

225 

^  _RETURN  _ 

226 

V9«  ISTAT  •  -5 

227 

228 

995  ISTAT  s  -6 

229 

RETURN 

230 

END 

231 

USER'S  SUlDE  PROCEDURES 


l,  PURPOSE 


G  1  v#  •  general  de»eniotion  of  the  program  atating  ite  purooae  end 
_ -iuntt  toft» _ 

.  .  2*. .  INP-UI _ 


aecuenc 1 ng( 


Describe  the  output  ineluding  format,  content*  and  output  media* 


operating  PROCEDURES 


List  the  atao  by  at eo  proeedurea  reouired  tol 


1.  Initiate  the  program* 


«  Maintain  operation* 


,  Terminate  and  reatart  the  Program, 


Give  an  operational  example. 


RESTRICTIONS 

Describe  any  Hm^tationa  aueh  a*  fire  of  input,  computer  oroceaeor 
used*.  .avate*.  » P_a.ce  required*  etc. _ 

PPL  1C  ABLE  ERRUR  M 


j.iat  any  error  goeaagg  which  may  be  dlaeiaved  due  to  improper  input, 
fife  generation  err on,  ate* 


.  J« _ PJURBQS 


allow  complete  onoceaalng  of  a»PI  p»ograma  «t  BmalC,  At  thU  t1me» 
_ aX.1  no  vara  <  on  of  tin  axiata  for  uw. _ This  veralan 

aceeota  a"  ordinary  u»P  I  Assembler  Input  *lle  and  eraataa  fr c»  It  a 

.  »vnt.a*ad  and  ef»n«r>1  arencad  .  VI 1 1  <  no  of  th»  Input. _ Por  complete 

documentation  on  the  use  of  the  eaaenbler,  refer  to  the  IBM  C P-2 

•  n if  /laP  T  manna  !  a 


2,-. INPUT _ 

_ T-fe La.  aaaattLlaP-.acceeta.-tlu 

th#  following  exceptional 


all  member  nam*  carda  *u»t  ba  delated  from  the  data  Beta. 


The  Outout  conalata  of  the  assembly  Hating  Including  error  messages, 
_ warnlnp  massages,  error  aumn,ry,  Input  file  description,  eroaa  r#» _ 


ferenee  dictionary*  external  iv«bol  dictionary,  special  rfar^a 
_  X a  rd»  L  an.d_t  ab  la  o  1  coPtab-U* _ 


operating  procedures 


a.l  Initial  Preparation  Procedun 


Before  .u 
to  oraea 
nodule  1 
si  nee  *e 
th 


A  Beear* 

e«r.da_  nu 
f  1 1 ena«e 
t  he  aboy 
the  nan# 
da  f  aul t  a 


el  jvg  j  h#_  aaaenbler  for  the  first  time,  It  la  necessary _ 

re  the  Input  fl'ea,  It  la  aaauned  that  th#  main  Input 

•. .  *i  ready  1  ocated  on  an  Interdata  dlae  each.  However# _ 

at  of  the  EYQLK8  realda  a*  data  acts  In  llbrarlea  at  Ogden, 
nuat  retrieve  thaae  data  aeta  for  uae  on  the  Interdat 


te  file  la  needed  Ter  each  EXBlK,  and  the  nenber  name 

at  be  deletad» _ Theat  fllea  nay  be  given  any  Interdata 

•  If  minimal  text  editing  of  fllea  ia  desired* 

a  fllea  should  be  named  ualnp  the  mti  _ 

from  the  INCLUDE  eardi  and  no  extension,  If  thaae 
are  not  uaedi  the  uaer  muat  modify 


«,2  OPERATION 


Th*  «»PI  Assembler  1*  a  non*lnt»nct  <vi  task, 
.  t.H*  -  jgllatd  Ja-J-Lai-aa  afl.t-1 _ _ 


ASHPI  flltxml 


f 1 1 tn» ma2 


where 

- fllenamel  i  m  thf  u«.r'«  Innut  i_LLa 

f n«''ai«ej  Is  the  user'*  output  tOe 


It 


1 a  called  by 


Option*  for  the  output  file  arej 


1,  filename  -  output  go**  to  the  *Pecffled  file 

- 2»..* _ «  Output1  Is  dlaplawed  on  tha  CRT  «creen _ 

>•  •  "  output  ooe*  to  a  null  device 

- H. - blaei _ ■output  ao.«  _  to  t  ha  user  'a  default  Hat  flip 

_ End  _fif_t  a  s  k.s  t  a  t  u  %  la  dl»p_l*yed  on  the  CRT  screen  as  fn  1 1  ovai 

_ EN0_0F__TASK_1>_ _ Assemh  led  ..a  1 1  h  no  error* _ 

END  OP  TASK  2  Assembled  with  wanning*  only 

ENp  OP  TASK  S  Aaaemhled  with  errors _ 

_ £  *  *mp let  .The. following!  IS  a  »hort  esample  of  a  Q»PI  or og  r«» 

and  an  INCLUDE  module  with  comment*! 

.  .  SOURCE 

/FRlHlOGNSJOfl _ (■A3S«.I,10,MHEC)>  ,QFP»,  CLASStE _ 

//STj'lSCR.SVSlN  DO  * 

_ _ //CPASMS.INCARDJIO  * _ 

A8SEW  A.NSSG 

The  abov*  card*,  *11  JCL  end  the  ASSEW  c*rd  are  treated  a* 

_ C omme nta  and  are  lonpred. _ _ _ 

ENTRY  ov_y  _ _ _ _ 

extrn  vshjet 

GAM80L  EXbLK _ _ _ _ _ 

INCLUDE  Gambol ~ 


Modui#  GamPOl  "u*t  h*ve  bean  brought  baek  fro*  Ogne",  separated 

iPto..lt*  own  filer  and  placed  on  the  user's  default  dl»£t _ Th* 

f 1 ie"a*»  must  have  blank*  In  the  extension. 


EC  OR _ PSSH  1 


losi*  _  _ explk _ 

*  INCLUDE  EP01 |ibB16,SRC/G 


CONEfOOCGUIOE.MAN 

28? 


16 


_.Aj-_ERROR  MESSAGES _ _ _ _ 

_ T»0  tyffe»  of  trrpri  are  Indicated  hv  the  aase-bler,  The  f  f  ra  t  d< a. 

o’»v»  bad  ftl*  I/O  to  the  CRT  •ereen»  g  W I  ng  t h*  (|ij  |«vc'ves  »n  a 
the  I/O  atatua*  This  tvpe  Includet  errors  tveh  as  a»»4on»e»t  errora 


ft r  the  <hPut  ®r  OotOyt  f^'*t  The  second  type  of  error  <g  for  avnta* 

_  aurora  and  w « r' r>  t  rq», _ Jhete  ate  Merged  Info  the  output _ 1 <  eti no  end 

appear,  beginning  1 n  eo1u"n  Zi  aa  followel 


*  WARNING  •••  «  ( 
aa  ERROR  »••  J  * 


warn  1_n_ga  and  Errors! 


_ warn  <  wga 


COLUMN  0  NOT  BLANK 

hultipl*  defined  LAREL 


I.  SHORT  IN8TR  DOESN’T  FOLLOW  A  SKIP,  CQmRaRE  OR  MODIF*  STORAG 


,  LONG  INSTRUCTION  GENERATED  IN  E*BLK 

•  SHORT  INSTRUCTION  GENERATED  _  _  _ 

,  'column  a  not  blank 

,  SHIFT  VALUE  TO  LARGE  --  HAS  BEEN  SET  TO  MAXIMUM _ _ 


•K,  EN'RY  or  extrn  DEFINED  BUT  not  USED 


feasibility  study  procedures 


6 


r jnfidoccuide.*un 


2,  Current  I*e1 ament at 1 an 


when  accessing  catted  unden  MTR02«  TC0Pv2  mutt  be  Implemented 
i_n_.no  J’ta dcr.nerte.  ...  A  usen.jyuat  user  the  ADV  tosmnn.la  BPHtisn  the 
tape  at  the  correct  tile. 


3,  Solutions 


1)  Rectify  TC0PV2  to  Ignore  the  account  number  field  In  the  hearten 

_ fllee. The  BfcbLrf  Hal  dltrussert  with  the  original  nrnprairme r 

»he  guooettert  that  the  ehanoe  eou'd  he  eagi'y  1  »pl  e"enf  rd,  The 
general  u»tr  noubj  be  able  _ihe._f.ltJP to  1  PC  ate- -a. 

file  on  the  taoe  and  then  proceed  with  g  R£iO  command,  The  tine  ;  <j 

coet  wi  i  LJ?e  30  _nen._hourx_eog  2ii  ajchj ne  h Auf, . _  ;  j 

*  1 

_2j_JU.»«-lh.e_jcwr..ren,t.  .lirpi.jtren.tat  1&n« — I-h-lS-je.aul-Tflg  ire  jum  .ta-f  :xai _  !  j 

ute  the  iwnfx  ce»*««d  todlaolav  •  He*  o«  «M  f  1 '  e*  on  tKe  t»oej  1 

the  count  the  number  Of  f11e*>  Including  both  hearten  ana  data _ _ _  } 

f1*e*«  and  u»e  the  *DV  Co*manrt  to  srtvanee  the  crooer  iu»fce'  o’ 
fl’nar  then  t u  1 1 c h  to  NqHE*DEb  node  and  proceed  »1th  t  P£*F _ 

COnnanO.  1 

3)  Peconn-enbat  1  on» 

_ _  \ 

l*  It  neconnendert  thet  TC0PY2  be  modified.  This  modification  *in  i 

n«kr  taoe  file  ecnultltlpn  lets  complicated  fo r  the  oenena'  uten,  i 


PREDICTIVE  SOFTWARE  COST  MODEL 


PERSONNEL  DESCRIPTION 


QATg.  28  Sept  1979 


F 


DESCRIPTION  OP  SKILL  LEVEL  AND  TYPE  (AF/CS/CONT)  OF  PERSONNEL  MAINTAINING  THIS  PACKAGE 

Below  is  the  official  position  description  for  a  GS-12  Electronic  Engineer 
(Computer  Systems).  This  description  outlines  the  basic  requirements  of  the  work 
to  be  done,  whether  performed  by  Civil  Service  or  contractor  personnel. 

I.  INTRODUCTION 

See  functional  statement  filed  in  Official  Position  Description  folder  and  the 
Sacramento  ALC  Organization  Directory  charts.  Incumbent  of  this  position  serves  as 
an  Avionics  System  Engineer  responsible  for  accomplishing  software  and  systems 
engineering  projects/tasks  for  avionics  embedded  computer  systems,  their  resident 
Operational  Flight  Programs  (OFPs)  and  their  support  systems  for  the  F-lll  and  other 
Sacramer.o  ALC  prime  air' -aft  systems. 

II.  DUTIES  AND  RESPONSIBILITIES 

1.  Develops,  coordinates  and  carries  through  to  completion  blocks  of  work  of 
large  scope  containing  many  phases  of  which  two  or  more  phases  each  contain  several 
complex  features.  Plans  and  conducts  research,  development,  or  other  work  for  which 
precedent  data,  criteria,  methods  or  techniques  are  significantly  inadequate,  are 
controversial,  or  contain  critical  gaps.  Develops  or  originates  completely  new 
features,  in  addition  to  improving,  extending,  or  validating  currently  known  pre¬ 
cedents,  data,  methods  or  techniques.  In  accomplishing  the  above  incumbent  is 
responsible  for  the  development  of  modifications  and  changes  to  complex  aircraft 
digital  avionics  systems,  their  Operational  Flight  Programs  (OFPs),  and  laboratory 
support  systems  (e.g.,  the  Sacramento  ALC  F-lll  Avionics  Integration  Support  Facility 
(AISF) )  In  addition,  incumbent  is  responsible  for  the  investigation,  analysis, 
evaluation  and  reporting  on  avionics  system  performance,  problems  and  new  requirements 

2.  Develops  and  carries  through  to  completion  complex  changes  to  the  OFPs. 

Uses  the  F-lll  AISF  to  analyze  and  evaluate  OFP  requirements  in  order  to  develop 
optimum  implementation.  Investigates  potential  solutions  to  system  problems /change 
requirements  considering  tradeoff  analyses  involving  implementation  costs,  algorithm 
developments,  timing  requirements,  memory  size,  hardware/software  integration 
requirements,  support  equipment,  personnel  capabilities  and  limitations,  data  package 
development  aid  overall  magnitude  of  the  effort;  and  translates  these  change  require¬ 
ments  into  engH  ering  specifications  and  tasks.  Designs  the  change  mechanization 
and  integration;  develops  the  programming  code;  and  debugs,  tests  and  documents  the 
results.  At  all  times  assures  aircraft  system  integrity  and  compatibility;  and  meets 
resource  allocations,  performance  criteria,  cost  and  schedule. 

3.  Establishes  formal  test  requirements  for  GfPs;  develops  and  implements  test 
plans;  conducts  detailed  tests  using  the  full  capabilities  of  the  F-lll  AISF  and 
instrumented  flight  test  aircraft;  and  analyzes,  evaluates  and  reports  test  results. 

4.  Serves  as  project  engineer  for  the  design  and  development  of  changes  and 
modifications  to  the  AISF  hardware/software  resources  and  other  avionics  support 
systems.  Provides  system  engineering  support  and  assures  compatibility  with  the 
aircraft  avionics,  digital  computer  complexes  and  OFPs.  Establishes  change  require¬ 
ments  directly  with  the  AISF  and  avionics  support  systems  users.  Prepares  change 
specifications  and  plans  and  schedules  the  complete  development  and  implementation. 

5.  Conducts  studies  and  evaluations  of  systems  in  acquisition  and  determines 
support  requirements.  Performs  2612  studies,  prepares  Computer  Resources  Integrated 
Support  Plans  (CRISPs)  and  participates  as  a  member  of  Computer  Resources  Working 
Groups  (CRWGs) . 
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( 

6.  Prepares  contractual  engineering  proposals  and  associated  specifications 
and  work  orders. 

7.  Monitors  and  maintains  close  liaison  between  contractor  and  Air  Force 
activities  associated  with  the  engineering  support  of  digital  avionics,  embedded 
computer  systems  and  OFPs  for  Sacramento  ALC  prime  aircraft  systems. 

8.  Reviews,  evaluates  and  advises  on  the  effectiveness,  technical  adequacy 
and  suitability  of  work  and  proposals  of  others  related  to  digital  avionics  and 
OFP  support.  Evalutes  more  complex  vendor  proposed  modifications  for  requirements, 
feasibility,  completeness,  accuracy,  cost,  and  operational  and  logistics  impact. 

9.  Consults,  coordinates  and  attends  conferences  with  other  service 
activities  and  higher  headquarters  on  matters  pertaining  to  avionics  OFP  develop¬ 
ment  and  support.  Makes  recommendations  to  higher  authority  for  changes  to 
policies  and  practices,  based  on  knowledge,  experience,  engineering  studies, 
observations,  and  reports  received  from  service  activites,  and  defends  Sacramento 
ALC’s  findings  and  recommendations.  Travels  to  contractor  or  other  government 
facilities  to  review  engineering  data  and  render  opinions  and  decisions  which  are 
normally  unreviewed;  maintains  liaison  with  other  government  activities  and  con¬ 
tractors  in  order  to  exchange  engineering  data  and  to  maintain  a  current  knowledge 

)  of  the  state-of-the-art. 

10.  Independently  determines  logical  approach  to  solutions  of  major  associated 
avionics  OFP  development  and  support  problems.  Carefully  weighs  the  advantages  of 
increased  systems  reliability,  maintainability,  etc.,  against  time,  cost,  com¬ 
patibility,  and  safety  of  flight.  Makes  and  evaluates  proposed  changes  to  the 
system  software  on  the  basis  of  established  hardware/sof tware  interfaces. 

Establishes  supporting  projects  with  other  engineering  personnel  and  directs  the 
integration  of  auxiliary  projects  toward  the  ultimate  objective.  Scope  of  project 
effort  is  broad  in  that  all  projects  consider,  as  applicable,  the  mission  of  the 
aircraft;  functions  of  associated  avionics  systems  (weapon  delivery,  navigation, 
reconnaissance,  radar,  instrumentation,  etc.);  communication/interface  requirements; 
flight  test;  computer  program  documentation  and  configuration  control;  and  vali¬ 
dation/verification  of  the  software.  Applied  research,  special  investigations, 
statistical  analysis,  etc.,  are  a  normal  part  of  the  incumbent’s  effort  in  accom¬ 
plishing  his  duties  and  responsibilities. 

III.  CONTROLS  OVER  WORK 

Incumbent  is  under  the  supervision  of  the  Section  Chief  and  receives  technical 
direction  from  the  functional  group  engineers  and  other  senior  engineers  who  give 
assignments  in  terms  of  broad,  general  objectives  and  relative  priority  of  work. 
Extent  and  limits  of  assignments  are  mutually  discussed.  Incumbent  works  with 
considerable  freedom  from  technical  control  in  selecting  and  establishing  the 
proper  methods  for  attacking  and  resolving  complex  features  and  otherwise  carrying 
assignments  through  to  completion.  Controversial  policy  questions  are  resolved  by 
joint  consideration  with  the  supervisor  and  functional  group  engineer.  Completed 
work  is  reviewed  for  adequacy  in  terms  of  broad  objectives  of  the  work  and  for 
compliance  with  Air  Force  policies  and  regulations.  Decisions  and  recommendations 
based  upon  application  of  standard  engineering  practices  are  rarely  changed  by 
higher  authority,  except  for  reasons  of  policy,  public  relations,  or  hidgetarv 
consideration. 
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IV.  OTHER  SIGNIFICANT  FACTS 


DATE:  28  Sept  1979 


1.  Fields  of  Engineering:  Electronic  -  55%,  Computer  Science  -  30% 

Aerospace  -  15% 

2.  In  addition  to  an  extensive  academic  and  professional  knowledge  of 
scientific  and  engineering  principles,  it  will  be  necessary  for  the  incumbent  to 
possess  a  special  faculty  to  do  successful  applied  research  and  establish  authori¬ 
tative  criteria  based  on  sound  engineering  principles  used  within  this  section  by 
joint  consideration  with  other  engineers.  At  most  times,  the  incumbent  will  be 
responsible  for  several  projects  requiring  difficult  and  advanced  engineering  work 
of  a  high  degree  of  originality,  therefore  incumbent  must  have  a  thorough  and 
detailed  knowledge  of  avionics  digital  systems,  (e.g.,  inertial  navigation  systems, 
fire  control  radars,  stores  management  systems;  digital  controls  and  displays, 
etc.);  aircraft  embedded  computer  systems;  real-time  operational  flight  software; 
laboratory  support  systems  to  include  real-time  simulation  systems,  host  computer 
systems  and  avionics  system  hot  mock-ups;  software  configuration  management; 
software  documentation;  OFP  testing,  evaluation,  verification  and  validation;  and 
aircraft  performance  and  operation,  specifically  in  the  areas  of  navigation  and 
weapon  delivery.  Must  be  experienced  and  knowledgeable  in  real-time  programming, 
mathematical  modeling,  computer  architecture  and  programming  languages. 

3.  Incumbent  must  possess  a  high  degree  of  professional  judgment,  skill, 
initiative,  planning  and  leadership  ability.  Also  must  possess  ability  to  maintain 
effective  personal  work  relationships  at  all  levels  and  to  justify  and  sell  his  own 
professional  viewpoints  in  conferences,  engineering  reviews  and  with  fairly  large 
groups  wherein  conflicting  points  of  view  are  represented.  Requires  an  intimate 
knowledge  of  functions,  organizational  structure,  jurisdictional  responsibilities, 
etc.,  of  USAF  and  elements  thereof. 

4.  The  incumbent  of  this  position  must  be  capable  and  willing  to  perform  TDY 
travel  in  accordance  with  the  Joint  Travel  Regulation. 

5.  Supports  and  takes  affirmative  actions  in  furtherance  of  Equal  Employment 
Opportunity  in  all  aspects  of  personnel  actions,  with  special  emphasis  on  Upward 
Mobility  and  other  special  programs. 

6.  Position  requires  a  security  clearance  of  Secret. 

7.  Performs  other  related  duties  as  required. 

8.  Subject  to  call  during  off-duty  hours. 

9.  All  personnel  will  share  in  the  responsibility  for  a  sound  industrial 
safety  program.  Incumbent  is  required  to  comply  with  all  applicable  safety 
directives.  Unsafe  conditions  are  to  be  promptly  reported  to  the  immediate 
supervisor. 
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10,800  ft.  of  standard  computer-type  facilities. 
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PREDICTIVE  SOFTWARE  COST  MODEL 

SOFTWARE  PACKAGE  CHARACTERISTICS  -  FACILITIES  (Cont) _ DATE:  28  Sent  1979 

COMPUTER  FACILITIES  (Type,  Quantity,  Application,  Coat  &  Usage) 

The  basic  equipment  in  the  F/FB-111  Avionics  Integration  Support  Facility 
is  as  follows : 

Equipment 

Dynamic  Simulation  System  (Harris) 

System  and  Software  Engineering 

Flight  Test  Data  Reduction  (PDF) 

Off-line  Computer  Support  (Interdata) 

Integration  Test  Equipment  @  1.7x3 
Original  cost  -  $800K  each 

Subsystem  Testers  (11) 

Avionics  (loaned  out  of  spare  assets) 

F-lllF/Pavetack  Dynamic  Simulation 

To  be  added: 

F-111A/E  Hardware 

Vendor  support  on  the  Harris,  Interdata  and  PDP  computers  costs  $308K/year 
plus  $126K/year  for  expendables  and  prototype  hardware  (split  50/50) . 


The  Avionics  Integration  Support  Facility  is  diagrammed  on  page  D-59. 
Specific  equipment  within  the  Harris/4,  which  contains  the  simulation  software, 
is  shown  on  page  D-60. 


Cost 

($  million) 

12.0 

1.5 
2.0 

5.1  (replacement 
cost) 

3.5  (replacement 

cost) 

12.9 

2.6 
39.6 

1.6 

41.2 
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Harris/4  System 
(Dynamic  Simulator) 

2  test  stations 

2  ADAGE  (large  display  screen  on  test  station) 

6  processors  -  80K  each 

2  SAS  (Simulation  and  Switching)  Interface  between  Harris  &  test  station 

6  CMACs  (Computer  Monitor  and  Control)  Interface  between  4pi  computer 

and  Harris 

1  card  reader 

1  card  punch 

2  paper  tape  readers 
8  mag  tape  drives 

1  CDC  line  printer 

2  Versatic  printer/plotters 
11  CRT 

2  teletypes 
6  10  mb  disc  drives 

1  40  mb  disc  drives 

2  300  mb  disc  drives 
1  paper  tape  punch 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  -  COMPUTER  FACILITIES 
TYPICAL  UTILIZATION  OF  HARRIS  COMPUTER 


_ DATE: 28  Sept  19 

WEEK  OF  23-27  July  1979 


Sat  Sun 


Harris 

(Maint) 


IV  &  V 


GD 

(Mod  if  & 
Upgrade) 


MMECS 

(Backup, 

Archive, 

etc.) 


IV  &  V 

Harris 

IV  &  V 

GD 

F 

IV  &  V 

F 

GD 

F 

. 

GD 

Harris 


IV  &  V 
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COMPUTER 

SOFTWARE  FUNCTION 

ESTIMATED 
SOURCE  LINES 

HARRIS 

SYSTEM 

292,953 

UTILITY 

34,494 

RJE 

7,410 

PLOTTER 

7,580 

OFP 

4.000 

ADAGE 

fc,714 

SAS 

2 , 888 

SIMULATOR 

17,  706 

CMAC 

13,674 

38  7.419 

Pages  D-63  through  D-71  provide  a  detailed  listing  of  the  relevant 
Harris  software. 
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HARRIS  F/FB- 
system  SOFTWARE 


SUP*  HAJNT 
PLlER  RES 


EST 

SOURCE 

LINES 


DESCRIPTION 


• 

• 

• 

ACLOhp 

- 

¥ 

,  XM/H 

-• 

100, 

ACUTIL 

M 

.IH/H 

1140. 

¥ 

.IH/H 

ISO. 

,  I  H/u 

» 

• 

JASLIB 

H 

.JH/h 

4060. 

jmooff 

* 

M 

,|H/H 

• 

120, 

;h<ion 

• 

IN 

-IN 

• 

100. 

• 

• 

« 

• 

;obol 

H 

,H/|H 

1 1  BO. 

3aT»pO0L 

W 

.H/JH 

1  000. 

)ISKCheck 

¥ 

t  h  / ;  k 

4 

80. 

'OBTAIN 

M 

•  u/!u 

172*0. 

JENCLIB 

h 

.h/JH 

300. 

iftran 

GEn/.GR/ ID 

1918. 

RES 

t 

isutil 

9 

¥ 

,H/I“ 

* 

440, 

• 

» 

• 

jobcnyrl 

¥ 

• 

20150. 

.FEDITOP 

H. 

.H/JH 

1860. 

ASUTJW 

M 

,h/;h 

l«l. 

J  COBOL 

H. 

a  H/JH 

R80, 

ARJNTF 

f 

¥ 

.M/IH 

• 

380. 

?PA  TCh 

• 

H 

!h/IH 

» 

• 

N/A  l 

IaMI*m 

IH 

.IH 

100. 

lAUTfST 

f 

IH 

.IH 

• 

10, 

• 

t 

• 

t 

TAPESORT 

H 

,h/JH 

N/A  . 

TEST 

IM 

.IH 

16. 

I L*R£L  . 

H 

..h/ih 

1*20, 

4  ! ACPY | V 

H 

.H/IH 

120. 

4 t  AC$M| V 

* 

H 

,M/IH 

260, 

SECTORS  USED  BY  EACH  USER 
SASIC  LIBRARY 

INITIATES  PROGRAM  ViCU0F|V  to  put  p»lhTFR 

Off  LINE  . . 

INITIATES  PROGRAM  VjCAON i V  To  PUT  PRINTER 
ON  LINE 

COBOL  COMPILER 

PROCESSES  DATA  AREAS  USED  BY  FORTRAN  COMPILER 
VERIFIES  INTERNAL  LOGIC  INTEGRITY  OF  THE  CISC 


I*iOE«EO  SEQUENTIAL  UTILITY  PRIMARILY  USED  FOR 
COBOL 

INTERACTIVE  USER  INTERFACE  TO  VULCAN 
LIBRARY  file  editor 
SPRY/MERGE  utility 
ANCILLARY  PROGRAM  used  BY  aCOBOL 
PROVIDES  octal  or  ASCII  DU«P  OF  SELECTED 
RECORDS  OF  A  FILE 
HARRIS  SUPPLIED  SYSTEM  PaTqh 
CHECKS  A  DISC  FOR  UNUSED  AHNo  SHARED  SECTORS 
EXERCISES  SCIENTIFIC  ARITHMETIC  UNIT  (SAL)  AND 
ABORTS  ON  ERROR 
SORTS  RECORDS  ON  TAPES 

EXERCISES  NULTIPLLICATION  FUNCTION  OF  SAU 

TAPE  LABEL  PROGRAM  . 

ACCOUNTING  RECORD  COPY  PROGRAM 
ANCILLARY  ACCOUNTING  UTILITY 
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/|A5CT|V 

M  .H/IH 

200, 

ACCOUNTING  SECTOR  READ/MRITE  service 

—XlAJLlY  .M/JM 

120. 

ANCILLARY  ACCOUNTING  UT1LITV  . 

/|BFm2|V 

H  ,H/JH 

160, 

BLOCKEO  DISC  AREA  HANDLER/EXTENSION 

/«blaN|V 

H  ,H/JH 

1200. 

BLOCKED  CISC  AREA  HANDLER 

StC40F|V 

H  ,JH 

120, 

DISCONNECTS  LINE  PRINTER  AND  CARO  READER 

/«C«0N|V 

H  .IH 

100. 

CONNECTS  LINE  PRINTER  AND  CARO  READER 

ViCBaSjV 

H  .H/JH 

I«0. 

BINARY  CODED  DECIMAL  TO  ASCII  CONVERSION 

YiCfASj y ... 

_ .H/IH 

-  .260. 

EBCDIC  TO  ASCII  CONVERSION  .  .  .  ...  _  .  _ 

/|CPOH|V 

H  .H/IH 

800. 

CARD  PUNCH  HANDLER 

/|CPBS|V 

H  .H/IH 

600. 

CONTROL  POINT  QUEUE  SWITCHER  PROGRAM 

/lC»DH|V 

M 

800. 

CARD  READER  HANDLER 

/|C«PH|V 

H  .H/IH 

1520. 

CARD  PUNCH  HANDLER 

/»CRTM|V 

H  .H/IH 

1860, 

HARRIS  CRT  HANDLER 

_ /«0!,MPl¥ _ 

..  H  .K/JM. 

.  240. 

POST  HOP  TEH  DUMP  GENERATOR . . .  ...  . 

/|DUhPeP« V 

H  ,H/IH 

000. 

REAL  TIME  PORTION  OX  DUMP  PROGRAH 

/l£K?3|V 

IH  .IH 

80. 

/  iCENS  |  V 

M  .H/IH 

1800. 

SYSTEM  GENERATION  MONITOR  PROGRAM 

/IHEADiV 

H  .H/IH 

340, 

LINE  PRINTER  HEADER  PAGE  GENERATOR 

*«IOaC|V 

H  ,H/IH 

• 

2200, 

DIRECT  MEMORY  ACCESS  CONTROL  PROCESSOR  SUPPORT 

__  _ .....  ...  _  - _ _  _ _ # 

.  MODULE  .  .  _  .....  .  .. 

/||HE*|V 

H  , H/IH 

80. 

INTERRUPT  EXECUTIVE  SERVICE 

/|JT8P|V 

H  .H/IH 

320. 

interactive  terminal  spooler  program 

'«lp0H|V 

H  ,H/IH 

780, 

UNIVERSAL  line  printer  HANDLER 

/|UPlH|V 

H  .H/IH 

1060. 

UNIVERSAL  LINE  PRINTER  HANDLER 

/»LP2HiV 

HK  ,H/|H 

980. 

VERSATEC  LINE  printer  handler 

_ H  ...H/IH 

840. 

ASYNCHRONOUS  line  PRINTER  handler 

1  |LPGD|V 

IH  .IH 

420. 

MODIFIED  LINE  PRINTER  HANDLER  FOR  GO  HEADER 

PAGE 

>  iME«D»y 

IH  .IH 

1200. 

CHECKS  OUT  C  PROCESSOR 

»|MESC|V 

H  ,H/IH 

680, 

MESSAGE  (SEND  RECEIVE)  SERVICE 

'lOLAVlV 

H  .H/JH 

960. 

OVERLAY  SERVICE 

.  '«OPC0|V 

_ H  .H/IH 

_  660. 

OPERATOR  COMMUNICATIONS  command  INTERPRETER 

'lOPcnv 

H  ,H/IH 

600. 

OPERATOR  COMMUNICATION  SEGMENTS  «  EACH 

PROCESSES  ONE  OR  MORE  OPCO”  commands 

'|0PC2»V 

H  .H/IH 

600, 

■  ■  R 

•ioPcs»y 

H  .H/IH 

900. 

a  a  a 

'|OPc«|V 

H  .H/IH 

620, 

run 

•jOpc5|V 

H  _.H/JM 

400. 

RUN 

•»0PC6|V 

H  .H/IH 

620, 

R  R  R 

•|OPc7jV 

H  .H/IH 

340. 

R  R  R 

■lOPespv 

H  .H/IH 

460. 

R  R  R 

■fOPcPiv 

H  .H/IH 

720. 

R  R  R 

|0PCA|V 

H  .H/IH 

480, 

R  R  R 

._-UBpCl|X__, 

H  ,M/JH 

-  720, 

R  R  R 

iopcciv 

H  .H/IH 

780. 

R  R  R 

«opcoiy 

H  .H/IH 

320. 

H  R  R 

lOPcXpV 

H  , H/ I H 

300, 

•  R  R 

lOpC2|V 

H  .H/IH 

140. 

a  r  r 

|P-PH|V 

IH  .  1 H 

1«5Q. HANDLER  FOR  HARRIS  END  OF  INTEROAT a. HARRIS  LINK 

.  jPl60|V 

IH  .  IH 

200. 

NON»Rf SIDENT  HANDLER  That  PUTS  OUT  GD  HEADER 

|PTpH|V 

H  .H/IH 

700, 

paper  tare  punch  handler 

iPTRHjV 

H  .H/IH 

380. 

rarer  tare  REAOER  handle* 

|PEHH|V 

H  .H/IH 

660. 

DISC  DIRECTORY  REHASH  SERVICE 

|R9C2|V 

H  .H/IH 

460, 

RESOURCE  ALLOCATION  SERVICE  -  P**T  2 

iRScXpV 

H  .H/IH 

520. 

RESOURCE  DEALLOCATION  SERVICE 

iRSRcpy 

H  .H/IH 

1120. 

RESOURCE  ALLOCATION  SERVICE 

I»TCX,V 

H  ,H/JH 

80. 

REAL  TIME  EXECUTIVE  PROGRAM  (USED  FOR 

• 

• 

• 

TIMER  SCHEDULING) 
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ifiTpHjV 

H 

.M/IH 

.  660 

.  iSCANt*  .  , 

...  H 

-- «H/IH — 

1220 

iSERVtV 

M 

,H/IH 

,  1080 

ISRV2IV 

M 

.H/IH 

.  sro 

ISY25JV 

M 

.H/IH 

,  640 

1 8  Y 1 1 1 V 

H 

.H/IH 

.  T40 

iSYIJpV 

H 

.H/IH 

• 

— |SYJS|_V. — 

—  M._ 

-H/IH  . 

.  ._  -1006 

«SYJ4»V 

M 

.H/IH 

,  1140 

|TEN2l V 

H 

.H/IH 

.  5*0 

iTENSiV 

H 

.H/IH 

.  BOO 

1 T  L  H 1  i  V 

M 

.H/IH 

.  1*60 

«YLM2jV 

H 

.H/JH 

.  2380 

iTLSSiY  „  N. 

.«H/IH 

.  -  .  TB.O, 

iTOAOiV 

H 

,  M/ 1  H 

.  1000 

»TRaP|V 

H 

.H/JH 

.  620 

|TTvH|V 

M 

.H/IH 

.  1760 

fUPRGjV 

N 

.H/IM 

.  200 

»UPUS|V 

W 

.H/IH 

.  180 

|US£RjY 

H 

-,H/iH._ 

380 

|US»C|V 

H 

.H/IH 

.  200 

ASS£M 

.H/JH 

.  6480 

BASIC 

H 

.H/IH 

.  4420 

ILCaNQO 

IH 

.IH 

.  18RR0 

— ULCANIZ  Ji  IH 

— .IH - 

. 200 

■  REF 

H 

.M/IH 

,  2060 

IBERY 

M 

.H/IH 

.124800 

|CASS|V 

H 

.H/IH 

.  1620 

r.flRP 

IH 

.IH 

.  10 

|ETC|V 

IH 

.IM 

.  120 

|UADR«V 

IH 

.IH 

,  100 

|Pmd 

H 

.H/IH 

.  1980 

TOTAL 

t 

• 

J292953 

REAL  TIME  PERIPHERAL  HANDLER 
FORMAT  SCANNER  SERVICE] 

BACKGROUND  SERVICES 
BACKGROUND  SERVICES 
SYSTEM  INITIALIZATION  PHASES 
SYSTEM  INITIALIZATION  PHASES 
SYSTEM  INITIALIZATION  PHASES 

-SYSTEM  INITIALIZATION  PHASES - 

SYSTEM  INITIALIZATION  PHASES 
PHASE  2  OF  VlTENSlV 
S  SECOND  SYSTEM  CHECK  PROGRAM 
TAPE  LABELING  SERVICE 
TAPE  LABELING  SERVICE 

.  TAPt  LABELING  SERVICE _ _  — . 

REAL  TIME  SERVICES 

VULCAN  EXECUTIVE  TRAP  SERVICE  ROUTINE 
TELETYPE  HANDLER 

USER  NUMBER  DISC  AREA  PURGE  PROGRAM 
UPDATE  USER  ACCOUNTING  SERVICE 

USER  NUMBER_LOOK  UP  SERVICE . -  . 

DISC  SPACE  DEALLOCATION  SERVICE 
ASSEMBLY  LANGUAGE  PROCESSOR 
BASIC  PROCESSOR 

DISC  COPY  OF  RESIDENT  VULCAN  THAT  IS  PUT  INTO 
MEMORY 

CREATES  LOAD  m0PULES  . .  .  .  . 

CROSS  REFERENCE  PROCESSOR 
HARRIS  SYSTEM  LIBRARY 
CASSETTE  HANDLER 

EXERCI8E8  EXPONENTIATION  FUNCTION  In  SAD 
NON-RESIDENT  HANDLER  FOR  Obtaining  CONTENTS 
ON  MEMORY  SYSTEM  ID,  AND  OAT  OF  THE  N££K 
ABSOLUTE  Disc  READS  FOR  USER  ROUTINES 
POST  MORTEM  DUMP 


HARRIS  F/FB 

utility  SOFTWARE 


:l  name 

SUP-  MAINT 
PLIER  RES 

— 

EST. _ 

SOURCE 

LINES 

N 

,IH  IH  , 

103 

.  -  —8 

'~OMPUTE~ 

.  IH  ,IM 

• 

515, 

opytape 

.  IH  ,IH 

8 

200. 

~c 

.  IH  ,IH 

• 

60, 

F 

.  IH  , I H 

• 

N/S  , 

FLMNgMAP 

.  IH  ,  I H 

8 

260, 

• LMNgVER 

.  -IH-.JH _ 

260. 

NTRr 

.  IH  .IN 

• 

140, 

cmTSNAPS 

.  IH  , I H 

• 

65, 

DESCRIPTION 


CONVERTS  NUMBER  TO/FROM  INTEGER*  OCTAL,  HEX, 

.  ASCII  AND  TASCII  .  .  . 

FLOATING  POINT  CALCULATOR 

copies  one  mag  tape  to  another 

DISPLAYS  SELECTED  LOCATIONS  OF  CORE 
DISPLAYS  HAPPING  INFORMATION  FOR  A  FILE 
ELIMINATES  FILES  IN  A  MAP  OUTPUT 
ELIMINATED  FILES  IN  AVER1FV  OUTPUT 
.COPIES  DATA  FROM  HP  TAPE  CASSETTE  TO  DISC  FILE 
SPOOLS  SNAPSHOT  OF  CRT  SCREEN  TO  PRINTER 
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enchd 

ft 

IH 

.IH 

m 

,  GENERATES  Command  file  used  IN  .TCOPY2 

_ pcq. 

_IH 

*IH 

.  N/S 

.  GENERAL  PURPOSE  COPT  ROUTINE  TO  SUPPOR  CAR. 

• 

» 

,  TRID6E  ON  HP  TERH1NAL 

*EEPCK 

• 

IN 

.IH 

J5«.  OUTPUTS  FORMATTED  LIST  OF  FILES  ON  A  KEEPt‘PE 

ft 

ft 

,  TO  THE  PRINTER  AND  VERIFIES  THE  TAPE 

F 

-ft 

IH 

.IH 

ft 

60. 

COMPARES  2  FILES 

PCOPY 

• 

IH 

.IH 

ft 

240, 

COPIES  A  MAG  TAPE  IN  KEEP/FElCH  FORMAT  TC 

. ANOTHER.  MAS  TAPE 

H 

• 

Tm~ 

Tin 

ft 

266, 

PROVIDES  A  LIST  OF  NHICH  LFN'8  ARE  currently 

• 

• 

. 

ASSIGNED  FROM  INTERACTIVE  TERMINAL 

*  e "User 

• 

h 

.H/IH 

SO. 

changes  QUALIFIER  AND/OR  user  number  OF  files 

-A*Chk 

ft 

IH 

.IH 

-ft 

99. 

LISTS  FILES  which  HAVE  HOT  BEEN  ACCESSED 

• 

• 

ft 

. 

SINCE  the  ENTERED  CUTOFF  Date 

—RLADFILE. 

IB. 

*-I  H - 

-LSBD.. 

.READS.  FILE  INTO  AN  OUTPUT  FILE  ADDING  PAGE 

ft 

ft 

ft 

. 

NUMBERS  and  CARRIAGE  CONTROL  FOR  SPOOLING 

ft 

ft 

ft 

. 

TO  THE  PRINTER 

5FETCM 

ft 

IH 

.IH 

ft 

220, 

CONSTRUCTS  A  JOB  STREAM  TO  FETCH  SELECTED 

ft 

ft 

ft 

• 

FILES  FROM  A  TAPE 

- NAPjT 

ft 

IM 

.IH 

ft 

40, 

SNAPSHOTS  THE  CONTENTS  OF  A  TEC-425  SCREEN 

_ 1C0PY2 _ 

— ft  -  - 

JH 

.IH.. 

.1132. 

READ/MRITE  FROM  DISC  TO  TAPE  AND  VISA-VER$A 

E 

ft 

IH 

.IH 

ft 

16257, 

TEXT  EDITOR 

HRUhS 

ft 

IH 

.IH 

ft 

600, 

transfers  files  between  PROCESSORS  THROUGH 

ft 

• 

ft 

« 

HIGH  SPEED  memory 

PEC  PY 

IH 

.IH 

BO. 

maxes  direct  binary  copy  from  tape  to  tape 

UBNqo 

• 

IH 

.IH 

ft 

40. 

ROTATES  printer  OUTPUT  90  deg. 

_ xref _ 

— ft.. 

I H _ 

-.IH. 

- ft-  - 

_240, 

PRODUCES  variable  and  file  name  CROSS  REFERENCE 

ft 

ft 

ft 

• 

FROM  an  ALPHABETIZED  LIST  OF  VARIABLES  AND 

• 

ft 

ft 

, 

FILES 

»tite 

ft 

I  H 

.IH 

ft 

200. 

ALLOWS  USER  to  write  TO  TAPE  CARTRIDGE  ON 

ft 

ft 

ft 

, 

HP  TERMINAL 

£0 

ft 

IH 

.IH 

ft 

ISO. 

SEOUENCES  SOURCE  FILES 

•SIMUIB  SIMULA* JON'libRaRV  CONTAINS  The  FOLLOWING  SUBROUTINES! 


l  TNMj 

.  IH 

.IH 

30. 

UNPACK  aREANAHE  FROM  TRUNCATED  ASCII  (4CPNJ 

ft 

• 

TO  STANDARD  ASCII  UCPW) 

TNMj 

.  IH 

|lH 

30, 

UNPACK  aREAName  from  TRUNCATED  ASCII  (aCPWl 

■-  ■  . 

-ft  .  .  .  - 

TO  STANDARD  ASCII  (SCPM) 

aslpon 

.  IH 

.IH 

« 

ASSIGN  LFN  (NON  RES0URCA8LE  PONiS  ONLY) 

JLCaS 

.  IH 

.IH 

55. 

ASSIGN  LPN  TO  CASSETTE  TAPE  ON  Tj  7J5 

slda 

.  I” 

.IH 

76. 

ASSIGN  LFN  TO  DISC  AREA  (FILENAME  AND  QUALI¬ 

ft 

ft 

FIER  REQUIRED) 

asldas 

.  1M 

.IH 

ft 

ASSIGN  LFN  TO  DISC  ARE*  (QUALIFIER  DEFAULTS 

ft 

TO  SIGN-ON  QUALIFIER) 

"Tlinf 

.  IN 

“  !  JN 

5fc  I 

ASSIGN  LFN  TO  ANOTHER  LFN  (FIRST  LFN  ASSlGNMEN 

ft 

ft 

FOLLOWS  SECOND) 

ASLINP 

.  IN 

1  IN 

ft 

ASSIGN  LFN  TO  ANOTHER  LFN  (FIRST  LFN  ASSIGNIN' 

ft 

ft 

ft 

DOES  NOT  FOLLOW  SECOND) 

SORT  I 

.  IH 

.IH 

102, 

ALPHANUMERIC  sort  on  an  array  jn  STANDARD 

-—ft— . 

ASCII  UC°W) 

SORTS 

'  IH 

.IH 

. 200* 

ALPHANUMERIC  SORT  on  an  array  in  STANDARD 

ft 

ft 

ft 

ASCII  CSCPW) 

ITOaJ 

.  IH 

.IN 

62, 

CONVERT  STANDARD  ASCII  UCPW)  to  standard 

• 

• 

ft 

ASCII  C3CPW) 

l  TOTC 

ft  IN 

.IH 

TO. 

CONVERT  standard  ASCII  UCPW)  TO  TRUNCATED 

ASCII  (4CPw> 

stoai 

IlH 

55! 

CONVERT  STANDARD  ASCII  C3CPN1  TO  STANDARD 

• 

ft 

ft 

ASCII  UCP») 
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iTora 

i* 

.IH 

“5. 

CONVERT  STANDARD  ASCII  (3CR*>  TO  TRUNCATED 

ASCII  c«mj  - 

-  I  NH£  X 

IH 

.IH 

X5 . 

BINARY  TO  WET 

-NPPT 

IH 

.IH 

200, 

BINARY  TO  PUNCH  paper  tape 

nohi 

IH 

.IH 

60. 

CONVERT  BINARY  (t  WORD)  TO  HEX  (ASCII  tCP“J 

t  T  OhJ 

IH 

.IH 

65. 

CONVERT  BINARY  (1  WORD )  TO  HEX  (ASCII  3CPM 

,FN»M 

IH 

.IH 

60. 

CHECK  LFN  ASSIGNMENT  STATUS  AND  OBTAIN  ASSIGN. 

MEN!  INFORMATION  - 

.UCBA 

IN 

.IH 

65. 

CONVERTS  BINARY  TO  ASCII 

.UIO 

IH 

.IH 

267. 

LONS  EORM  OF  STANDARD  CALL  FOR  I/O  SERVICE 

3LUJ0A 

IH 

.IH 

CALL  FOR  I/O  SERVICE  TO  RETURN  CONTENTS  OF 

• 

a 

A-REGISTER  AFTER  I/O 

JLUIOC 

IH 

f  U 

CALL  FOR  1/0  SERVICE  FOR  CHARACTER  I/O 

-1LUI0E 

.IH. 

I H  . 

CALL  FOR  I/O  SERVICE  TO  RETURN  CONTENTS  OF 

E-REGISTER  AFTER  I/O 

JLUIOS 

1“ 

SHORT  FORH  OF  STANDARD  CALL  FOR  I/O  SERVICE 

JLL'IOo 

IN 

.IH 

long  FOR-  OF  standard  CALL  FOR  I/O  SERVICE 

REQUESTING  A  WAIT  AFTERWARDS 

.ULFN 

IH 

.IH 

62. 

CHECK  LFN  ASSIGNMENT  STATUS 

,UPrtN 

I H 

.IM 

55. 

CHECK  PON  CHARACTERISTICS 

HXgl 

IH 

.IH 

46, 

CONVERT  HEX  (ASCII)  TO  BINARY  Cl  WORD) 

/  SVSP 

IH 

.IH 

60. 

CONVERT  SYSTEM  DATE/TIME  IN  STINE  FCRMAT 

TO  ASCII  (MILITARY  FORMAT) 

ITE 

IH 

.IH 

<2. 

OBTAIN  CURRENT  DATE  AND  TI*E  FROM  SYSTEM 

[NF01 

IH 

.IH 

205, 

OBTAIN  LIMITED  INFORMATION  ON  A  SPECIFIC 

■  -  -  -a 

DISC  FILE  .  .  . 

n«jro2 

IH 

.IH 

obtain  moderate  amount  of  information  on  a 

SPECIFIC  DISC  FILE 

)INF03 

a 

IH 

.IH 

OBTAIN  COMPLETE  INFORMATION  ON  A  SPECIFIC 

• 

DISC  FILE 

nosi 

IH 

.IH 

223. 

SCANS  AND  CONVERTS  ASCII  DATE/TIME  (mjl  0r 

JULIAN  FORMAT)  TO  BINARY 

USE 

IH 

.  IH 

75. 

CLEAR  TERMINAL  SCREEN 

.MNe 

IH 

.IH 

76. 

ELIMINATE  A  SPECIFIC  DISC  FILE  (QUALIFIER  AND 

• 

a 

FILENAME  REQUIRED) 

»L«NSS 

a 

IH 

.IH 

ELIMINATE  A  SPECIFIC  DISC  FILE  (SIGN.ON) 

qualifier  ASSUMED) 

(NDc^ 

IH 

.IH  . 

I7«. 

FINO  OCCURRENCE  OF  CHARACTER  In  CHARACTER 

STRING  FROM  A  GIVEN  OFFSET 

fNDTX 

IH 

.  IH 

226. 

FJNO  occurrence  OF  a  CHARACTER  STRING  IN  a 

LARGER  STRING 

»P 

T  H 

.IH 

362, 

CONVERT  ASCII  REPRESENTATION  OF  A  floating 

POINT  TO  INTERNAL  FLOATING  point  format 

.SPIT 

IH 

.IH 

64. 

SET  A  SPECIFIED  bit  in  an  array 

<TLaT 

IH 

.IH 

163, 

format  IATITUOE/LON6JTUOE  into  ASCII 

«tlon 

IH 

.1“ 

format  LATITUDE/LONGITURD  into  ASCII 

»STCW 

IH 

.IH 

62. 

FINO  FIRST  nonblank  CHARACTER  IN  a  CHARACTER 

STRING 

1 C  AN 

IH 

.IH 

265, 

CALL  TO  SYSTEM  FORMAT  SCANNER  SERVICE 

IH 

..IH 

165. 

GENERATE  A  DISC  FILE  KITH  ACCOUNT  ACCESS 

(SHORT  FORM) 

JNOL 

IH 

.IH 

GENERATE  A  DISC  file  (LONG  FORM) 

»NDO 

IH 

.IH 

GENERATE  A  DISC  FILE  KITH  OWNER  ACCESS  ONLY 

(SHORT  FORM) 

*NOP 

IH 

.IH 

GENERATE  A  DISC  FILE  MITH  PUBLIC  ACCESS 

(SHORT  FORM) 

IXBJN 

IH 

.IH 

ISO. 

CONVERT  H£X  TO  BINARY 

;xin 

a 

IH 

.IH 

a 

94. 

INPUT  AND  CONVERT  HEX  ASCII  (UR  TO  6  CHARACTERS 

3m 
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• 

TO  BINARY  (1  WORD) 

..  -»*»PT 

.  IH 

.IM 

164. 

OATA  UN  HEX)  TO  PUNCH  PAPER  TAPE 

•  0RT3 

,  Th 

.IM 

96. 

HE*  SORT  ON  ASCII  REPRESENTATION  OP  HE* 

NUMBERS  in  an  array 

|T08I 

.  I" 

.IM 

82. 

CONVERT  HE*  (ASCII  ICPM)  TO  BINARY  (1  WORD) 

:  jptn 

.  I* 

.IM 

’5. 

OBTAIN  PROGRAM  OPTIONS  PROM  PROGRAM  OPTION 

• 

• 

wORO  PROM  INITIALIZATION 

ILNBK 

.  IH 

.IM 

ANOTHER  .ENTRY  POINT  FOPFRSTCH  - 

*  J  JUAN 

,  IM 

.IM 

115. 

CONVERT  RETURN  PROM  SYSTEM  StlME  SERVICE  TO 

JULIAN  FORM  DATE  AND  TIME 

»P4PI 

.  IM 

•  IH 

60. 

CONVERT  A  HARRIS  FLOATING  PONT  NUMBER  TO  API 

• 

• 

FIXED  POINT  NUMBER 

jmpar 

.  I” 

.IM 

122. 

COMPARE  CHARACTER  STRINGS 

—  18ICH 

.  IH 

--.IM 

93, 

PINO  LAST  NONBLANK.  CHARACTERS  IN  A  CHARACTER  — 

• 

• 

STRING 

(SUNG 

.  IM 

.IM 

3)2. 

COPY  FILE  TO  FILE  PITH  PRINTER  SPACING 

ITmbk 

.  IM 

.IM 

ANOTHER  ENTRY  POINT  FOR  LA8TCM 

‘  JVCSR 

.  IH 

.IM 

• 

52. 

HOVE  CURSOR  ON  THE  TEKTRONIX  4019 

1 CHR 

.  IM 

.IM 

too. 

MOVE  OAY A  IN  AN  ARRAY 

_;.»p.*rn  .  im 

_IH 

75. 

SCAN  OFP  CKAN6E/PRQBLEM  DESCRIPTION 

7HRT  4 

.  IM 

.IH 

65. 

TRUNCATE  and  INSERT  ASCII  CHARACTER  IN  A 

• 

• 

TRUNCATED  ASCII  ARRAY  C4CPW) 

»MOPT 

.  IM 

.IH 

99, 

OBTAIN  program  OPTIONS  and  PARAMETERS  at 

program  INITIALIZATION 

•  TLDS 

.  I” 

.IM 

63. 

punch  paper  tape  leader 

'TUT  .... 

.-  IH 

.  ...IM. 

35. 

PUNCH  PAPER  TPAE  TITLE 

TCHAR 

.  IM 

.IH 

197. 

CONVERT  ASCII  CHARACTER  To  PAPER  tape  code 

»n*hE 

.  IM 

.IM 

86. 

rename  A  DISC  PILE  TO  A  hem  name  (QUALIFIER 

• 

AND  FILENAME  REQUIRED) 

*Enamj 

.  IM 

.IH 

• 

RENAME  A  OISC  FILE  TO  a  NEM  name  (SIGN.ON) 

• 

QUALIFIER  ASSUMED) 

JTtpE 

.-  .  I” 

...IH 

100. 

RETYPE  a  DISC  file  to  a  N£W  type  SPECIFICATION 

(LONG  FORM) 

•  ETYP8 

.  IM 

.IH 

• 

• 

RETYPE  A  DISC  FjlE  TO  *  NEW  TYPE  SPECIFICATION 

• 

B 

(SHORT  FORM) 

•TBIN 

.  IM 

.IH 

1®9, 

READ  PAPER  TPAE  AND  CONVERT  TO  BINARY 

•  The* 

.  IM 

.IH 

179, 

READ  PAPER  TPAE  AND  CONVERT  TO  HE* 

lose 

.  I” 

.IM 1. 

85, 

RESOURSE  DISC  PACK 

ISOSCT 

.  I” 

.IH 

TEST  DISC  RESOURCE  REQUEST 

ISDSC" 

,  IH 

.IM 

• 

SPECIFY  A  WAIT  UNTIL  RESOURCE  REQUEST  FOR  DISC 

PACK  HAS  BEEN  FULFILLED 

IHSM 

,  !H 

.IM 

75. 

RESOURCE  high  SPEED  MEMORY 

JSHSMT 

,  IH 

.IH 

• 

TEST  HIGH  SPEED  MEMORY  request 

IShjhk  . _ JH 

-.IH  - 

SPECIFY  a  WAIT  UNTIL  RESOUCE  REQUEST  FOR 

HIGH  SPEED  H£HORT  FULFILLED 

»mtl 

.  IH 

.IH 

105. 

RESOURCE  MAG  TaPE  (LONG  FORM) 

•smtlt 

.  IM 

.IM 

• 

test  mag  tape  resource  request  (long  form) 

•  SMTLW 

.  IM 

.IM 

SPECIFY  A  wait  UNTIL  RESOURCE  REQUEST  FOR 

• 

MAG  TAPE  mas  BEEN  FULFILLED 

»MTJ 

« _ IM 

.IH  .. 

86, 

RESOURCE  MAG  TAPE  (SHORT  FORM) 

TSMTST 

.  IM 

.IM 

■ 

TEST  MAG  TAPE  RESOURCE  REQUEST  (LONG  FORM) 

•  SMTSW 

.  IM 

.IM 

SPECIFY  A  wait  until  RESOURCE  REQUEST  FOR  MAG 

• 

Tape  has  seen  fulfilled 

•  PON 

.  IM 

.IM 

86, 

RESOURCE  PON  (MUST  BE  RESOURCEABLE) 

•SPONT 

,  IH 

.IH 

TEST  PON  RESOURCE  REQUEST 

•SPpNw 

..  IH 

.IM- 

SPECIFY  A  WAIT  UNTIL  RESOURCE  REOUEST  FOR  FDN 

HAS  BEEN  FULFILLED 

JTBJT 

,  IH 

.IH 

• 

51. 

SET  FIT  IN  A  VECTOR  *RRAY 
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)RT 

IM 

.1H 

.  RO, 

BINARY  SORT  ON  AN 

ARRAY 

BV  ROM 

1Z- 

IH_ 

-.IH 

,  62. 

SQUEEZE  BLOCKED  DISC  FILE  TO  MIN, 

requirement 

iozub 

0 

IH 

.XH 

SQUEEZE  AN  UNBLOCKED  DISC  FILE 

TO 

MINIMUM 

REQUIREMENTS 

A  T  0  A 1 

1 

!H 

.IM 

.  61, 

CONVERT  TRUNCATED 

ASCII 

(ttPCM) 

TO 

STANDARD 

-  • 

• 

ASCII  (ICPM) 

1T0A3 

IM 

.IM 

.  «7, 

CONVERT  TRUNCATED 

ASCII 

(RCPM) 

TO 

STANDARD 

— 

*  ■  -• — 

— 

-  •  -  - 

-  ASCII  CICPtt) 

-  - 

-  -  -■ 

— 

)TAL 

• 

• 

• 

• 

* 

_  HARRIS  F/FB  _ 

RJE  (REMOTE  JOB  CONTROL)  SOFTWARE 


EST 

..JUR- _ MAINT.  S0U»CE 


(  na«E 

PLIEO 

RES 

LINES 

DESCRIPTION 

:/masp 

H 

'.m/ih 

• 

5220 1 

SPOOLER  FOR  RJE 

:nde« 

IM 

.I” 

10. 

SCANS  RJE  FILE  and  WRITES  A  LIST  OF  CRITICAL 

WARNING  or  ERRORS 

'C.RJE 

H 

,  M/ 1 H 

160, 

OPCOM  RJE  DRIVER 

IE 

w 

.H/IH 

1000, 

REMOTE  JOB  ENTRY  PROCESSOR 

IE»T? 

IM 

.IM 

1300, 

WRITES  A  LIST  FORMAT  RJE  DATA  FILE  TO  mag  TAPE 

FOR  LISTING  OR  MICROFICHE 

iegen 

H 

.M/IM 

560, 

parameter  generation  program  used  in  configur. 

INC  INE  IBM  SITES  INITIATED  flV  ‘RJE  .. 

<bert»v 

H 

.M/IM 

180, 

RJE  UTILITY 

•RJEMjV 

N 

.M/IM 

• 

R80, 

REMOTE  JOB  ENTRY  HANDLER 

)TAL 

• 

0 

0 

• 

T«lo| 

HARRIS  P/FB 
PLOTTER  SOFTWARE 


EST 

SUP.  HA  J  NT  SOURCE 

:  FILE  PLIER  RES  lines  DESCRIPTION 


§00,  DATA  RETRIEVAL  RLOTTInO  RROORAm 
160,  PLOTS  WEAPON  SCORING  RELEASES  RRODUCEO  BV 
,  ‘SCORE 

mo,  VERSATEC  plotter  routine 
RRfeO,  VE»SATEC  PLOTTER  LIBRA*) 

*00,  REPLOTS  OR  ELIMINATES  AREAS  CREATED  »V  USING 
.  ‘SCORE#  KEEP  OPTION  .. 

7580 1 


1TRETPL 

IH 

_jXH 

'PLOT 

• 

IM 

.IM 

•LOT 

0 

• 

H 

!m/im 

.otlib 

0 

M 

.M/IH 

IPLOT 

0 

IH 

.IH 

ITAL 

• 

0 

- 

0 

0 

303 


■  a— 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET _ DATE:  28  Sent  197 


HARRIS  F/FB 

aimitAJOR  software 

EST 


su*>« 

1  name  PLIED 

MAIN! 

res 

SOURCE 

Lines 

DESCRIPTION 

)RS  | 

Th 

- 

.IH 

-♦ - *- 

.  216. 

GENERATES  ADDRESS  AND  CROSS  REFERENCE  INFORMA- 

TION  FOR  monitor  COMMON  variables 

»LLIS 

IH 

.IH 

.  soo. 

COMPUTES  ballistic  curves 

<FR 

IM 

.IH 

.  200. 

LOADS  C  PROCESSOR 

kTRET 

IH 

.IH 

.  2860 , 

RETRIEVES  SIMULATION  data 

»tretqo_._ 

IH. 

-.I H  .. 

.  160. 

QUICK  and  DJRTV  data  retrieval  PROGRAM 

•SPEC 

IH 

.IH 

.  2200, 

SETS  UP  DATA  RECORDING  FILE 

i 

IH 

.IH 

.  60, 

FUNCTION  WORD  ASSEMBLER 

•3MLC  . 

IH 

.IH 

.  160, 

KEEP  AND  FETCH  aSTMLOG  ON  TaPE 

1NIT0R  , 

IH 

.IH 

.  1«0. 

MONITORS  MEMORV  LOCATIONS  AND  REPORTS  ant 

• 

•  • 

CHANGES  IN  VALUE 

IH 

.I” 

.-  «320. 

MISSION  PLANNING  PROGRAM 

,A*UTIl  , 

IH 

.IH 

.  1600, 

planning  file  utilitv  progpam 

»T,LDJ5  , 

IH 

.IH 

.  20, 

RESIDENT  REAL  TIME  LOADER  FOR  *V|L0J5|V 

:o»E 

IH 

.IH 

.  500, 

CONFUTES  The  IMPACT  POINT  OF  SIMULATION  F'EaPON 

RELEASES 

{RIAL 

IH 

.lH 

.  mo. 

MONITORS  SIMULATION  SERIAL  DATA  NORD  COUNTS 

:td*t 

IH 

-.IH 

.  039. 

PUTS  A  KNQNN  VALUE  IN  MONITOR  COMMON 

9  % 

IH 

.IH 

.  200. 

INITIATES  THE  START  OF  SIMULATION 

•DATE  , 

IH 

.IH 

.  220, 

UPDATES  MONITOR  COMMON  DISC  FILES  USED  BY  TH£ 

SIMULATION  DISPLAY  PROGRAMS 

|A0RS|V  , 

IH 

.IH 

.  SO, 

COMPUTES  SEMICONDUCTOR  MEMORY  LOCATION  OF 

MONITOR  COMMON  VARIABLES 

.  |CLpR|V  , 

IH 

-.IH. 

.  200, 

LOADS  A  PROGRAM  IN  C  PROCESSOR  F»OM  EITHER 

A  OR  S  PROCESSOR 

tlHTOlV  , 

IH 

.IH 

,  200, 

interrup  handler  for  simulator  softkare  on 

A  PROCESSOR 

|L0J5|V  , 

IH 

.IH 

.  O0, 

SETS  UPM0NJT0R  SERVICE  BLUJS  FOR  NON-RESIDENT 

■ 

«  • 

HANDLER  »V|ETC|V 

IM 

.IH 

.  500, 

SETS  UP  MONITOR  SERVICE  BLUJ6  ON  A  PROCESSOR 

ISRCBIV  . 

IH 

.IH 

.  TOO, 

SETS  UP  MONITOR  SERVICE  BLUJ6  ON  B  PROCESSOR 

IEFBNAF  , 

IH 

.IH 

.  100, 

PRODECES  FORMATTED  LISTING  OF  ALL  SIMULATION 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:28 


$DRIV£ 

4 

JM 

.!« 

«  100 

IEFQ 

0 

IM 

.IH 

.  200 

»£pgp 

• 

• 

IH 

• 

.  700 

'PLAN 

• 

• 

!H 

• 

• 

.’  56  0 

3TAL 

• 

• 

• 

• 

*  17706 

COWHANDS 

RESC0RE8  neapon  DROPS  B*  THE  SIMULATOR 
PROVIDES  A  LISTING  OP  simulation  MONITOR 
COMMON  VARIABLES  IN  pile 
UPDATES  CROSS-REFVERENCE  PILES  USEO  BY 
•CMACRETV  and  *Px 

RESTRUCTURES  PLANNING  PILES  To  THE  NEw  5  OPPSET 


HARRIS  F/FB 
CMAC  SOPTWAPE 


EST 

SUP-  HAINT  source 


- 1  name  . 

PLIED  »£S 

LINES 

atalog 

IH 

. 

.IH 

• 

360 

.OCKS 

IM 

.IH 

eo 

.OCKT 

IM 

•  IH 

100 

WACDIAC 

IH 

.IM  „ 

.  VQUO 

WACRETV 

IM 

.IH 

29<iV 

WACTEST 

IM 

.IH 

a  oao 

WACTIme 

IM 

.IH 

160 

jmptp 

IH. 

.JN 

140 

SRET 

IH 

.IH 

• 

134 

""  ! CMAC 1 V 

IH 

‘iM 

• 

• 

1700 

0T*L 

IM 

0 

.1* 

• 

• 

13674 

DESCRIPTION 


CREATES  CMAC  LOAD  POP  F/PB  ASTRO 

CHECKS  CLOCKS  ON  CHAC 

READS  THE  CLOCK  PROM  ALL  S  CHAC»S 

CMAC. DIAGNPSITICS 

Retrieves  CMac  Data 

ALLOWS  USER  TO  COMMUNICATE  nITh  CMAC 
CONVERTS  CMAC  COARSE  ANO  FUa 
OU-PS  CMAC  RECORDING 

CMAC  OATA  Retrieval  PROGRAM  FDR  RETRIEVING 
PULL  SNAPSHOTS 

SETS  UP  MONITOR  SERVICE  BLUjfl  FOR  COMMUNICATION 
WITH  CMAC 
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PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  - 
FLIGHT  TEST  REQUIREMENTS _ 


DATE:  28  Sept  1979 


None.  Each  change  is  checked  out  in  accordance  with  normal  debug 
procedures  for  a  simulation  package. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  -  TRAINING  REQUIREMENTS 
PROGRAMMER  TRAINING: 

OJT  -  Forth  Worth  (General  Dynamics) 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  MAINTENANCE  HISTORY _ DATE:  28  Sept  1979 


DESCRIPTION 
SINCE  PMRT 

OF  NUMBERS  AND  TYPES  OF  MAINTENANCE 

ACTIONS  PERFORMED  EACH 

YEAR 

Log  No. 

Title 

Req  Dt 

Comp  Dt 

Man  Hours 

Hardware  Software 

SS76-001 

Ref.  Engage  Switch 

25May78 

18Jul78 

16 

80 

SS76-002 

Autopilot  Engage  Dlscrep 

25May78 

08Jun78 

— 

24 

SS77-005 

Radar  Alt  Break  Lock  Limit 

01Sep77 

23Sep77 

— 

1 

SS77-009 

Atmosphere  Model  Error 

01Sep77 

23Sep77 

— 

8 

SS77-010 

Takeoff  Trim  Button 

01Sep77 

17Jul78 

16 

24 

SS77-011 

OFP-F  Pitch  System  Alt 

01Sep77 

22Sep77 

— 

8 

SS77-012 

Wpn  Scoring:  CBU-30 

01Sep77 

260ct77 

— 

2 

SS77-013 

Wpn  Scoring:  M61  Bay  Gun 

01Sep77 

260ct77 

— 

4 

SS77-014 

Wpn  Scoring:  MK.-36 

01Sep77 

09Dec.77 

— 

4 

SS77-015 

Wpn  Scoring:  Wpn  //4 

01Sep77 

260ct77 

— 

2 

SS7 7-016 

Wpn  Scoring:  Wpn  #20 

01Sep77 

260ct77 

— 

2 

SS77-017 

Wpn  Scoring:  Wpn  #9 

01Sep77 

260ct77 

— 

2 

SS77-018 

Wpn  Scoring:  Wpn  #10 

01Sep77 

260ct77 

— 

2 

SS77-019 

Wpn  Scoring:  Wpn  #20 

01Sep77 

260ct77 

— 

2 

SS77-020 

Wpn  Scoring:  Wpn  #27 

01Sep77 

260ct77 

— 

2 

SS77-021 

F-111F  SMS  Stn  3/6 

01Sep77 

23Sep77 

— 

4 

SS77-022 

F-111F  SMS  Stn  1/8 

01Sep77 

23Sep77 

— 

4 

SS77-042 

Wpn  ID  Cross  Index  Disp 

13Sep77 

lAug77 

— 

16 

SS77-046 

Grid  Identifiers 

08Sep77 

28Nov77 

— 

16 

3S77-051 

Winds  and  Errors  in  Sim 

01Jun77 

19Dec77 

— 

180? 

SS77-052 

Recage  Irm  X-Axis 

01Jun77 

18Nov77 

— 

60 

SS77-053 

Wind  Table  Interpolation 

N/A 

28Nov77 

— 

2 

SS77-054 

Std  Atmosphere  Model 

N/A 

170ct77 

— 

8 

SS77-055 

Simulator  0DSS  Problem 

N/A 

28Nov77 

— 

2 

SS7 7-062 

ODSS-Air  Discrete  Loss 

N/2 

28Nov77 

— 

12 

SS77-063 

Wpn  Scoring  Errors 

05Jul77 

31Aug78 

— 

80 

SS77-085 

Altitude  Cal  Problem 

15Sep77 

28Nov77 

— 

1 

SS77-090 

Inconsistent  Wpn  Names 

22Sep77 

28Nov77 

— 

8 

SS77/094 

Wpn  Scoring  Printouts 

060ct77 

050c t 78 

— 

80 

SS77-133 

D-Bugs 

15Dec77 

28Aug78 

— 

200 

SS> 7-138 

Non-Functioning  SW0  HDI/HS 

25May78 

08Jun78 

— 

8 

SS77-139 

"SIM  Time"  Backs-up  Interm 

25May78 

D8Jun78 

— 

4 

S3"7-140 

SIM  Lack  of  Four  OAPs 

25May78 

14Aug78 

400 

PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET _  _  QATi;  28  Sept  1979 


Man  Hours 


Log  No 

Title 

Req  Dt 

Comp  Dt 

Hardware  Software 

SS77-141 

"SDD  NDUZ"  Values  Not  Disp 

25May78 

08Jun78 

— 

16 

SS78-023 

FB  Test  Stn  SRAM  Integ 

23Feb78 

Open 

SS78-027 

Wind  Table  Interpolation 

02Mar78 

06Apr78 

— 

1 

SS78-054 

Immediate  INS  Align  Upon  R 

13Apr78 

260ct78 

Unknown 

SS7 8-056 

F/FB  DTS  Update  for  FB16 

13Apr78 

17Jul79 

Unknown 

SS78-058 

Non-Std  Atmosphere  MO 

13Apr78 

28Aug78 

— 

60 

SS78-078 

Loss  of  *PIan  Updates 

04May78 

17Jul78 

— 

14 

SS78-092 

D19  Sim  Problems 

01Jun78 

Q6Apr79 

Unknown 

SS78-106 

Take-off  Pitch  Angle 

29 Jun78 

060c t 78 

— 

80 

SS78-109 

Pod  Slant  Range  Wrong 

29Jun78 

310c t 78 

— 

1 

S78-110 

Pod  Mode  Display  Errors 

29Jun78 

28Sep78 

Unknown 

SS78-112 

Pod  Tracking  Handle  &  TH 

29Jun78 

02Apr79 

— 

40 

SS78-114 

Burst  Event  Based  on  Time 

29Jun78 

17Aug78 

— 

20 

SS78-115 

"Hdg  Nav"  Autopilot  Errors 

29Jun78 

29Nov78 

— 

8 

SS78-121 

Roll  Autopilot  Problems 

13Jul78 

17Aug78 

— 

20 

SS78-124 

Modification  of  Winds 

20Jul78 

28Aug78 

— 

0.3 

SS78-157 

CBU  Timer  Toss  Ripple 

060ct78 

29Nov78 

— 

4 

S78-166 

*PLOTIT  Grid 

20Nov78 

22Jan79 

— 

3 

SS79-020 

D-Sim  Heading  Error 

18Apr79 

08Jun79 

Unknown 
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PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  MAINTENANCE  COST  HISTORY _ DATE:  28  Sept  197; 

YEARLY  COST  OF  MAINTAINING  PACKAGE:  I 


Total  AISF  support  requires  approximately  ten  on-site  contractor  personnel, 
plus  five  to  ten  personnel  at  General  Dynamics  involved  in  major  upgrades. 


PREDICTIVE  SOFTWARE  COST  MODEL 


HISTORICAL  DATA  SOURCES 


DATc.  28  Sept  1979 


Data  Base  Name: 


AISF  Task  Listing 


Location : 


SM-ALC/MMECP,  McClellan  AFB,  California 


Contact  Person: 


Alton  E.  Patterson 


Phone  Number : 


(916)  643-4762 


General  Contents: 


Listing  of  all  hardware  and  software  modifications 
to  the  AISF.  Manhour  data  can  be  recovered  from 
the  individual  task  data  in  the  files. 


Period  Covered: 


FY’77  through  FY'79 


Data  Quality: 


Good  detail  on  individual  tasks 


PREDICTIVE  SOFTWARE  COST  MODEL 


RECOMMENDATIONS  RE  SOFTWARE  SUPPORT  COST  PREDICTING 


RESPONDENT:  Bassett 


DATE.  28  Sept  1979 


It  you  were  responsible  for  predicting,  accumulating  and  accounting  for  software 
support  costs,  how  would  you  do  it? 

1.  AF  Flight  simulator  concept  (requirements  different  than  A/C)  -  Need  to  be 
able  to  update  flight  simulator  by  just  changing  OFP  software. 

2.  a.  Demand  spare  memory 

b.  Language  -  Function  of  application 

Need  to  study  tradeoff  between  ease  of  development/maintenance  vs. 
operational  requirements  (efficient  code) 

Can  HOL  support  those  requirements? 

Support  -  peculiar  language  -  need  to  buy  original  contractor 

c.  Mission  requirements 

TAC  has  more  precise  testing  requirements  than  SAC. 

(Weapon  delivery  precision)  [smart  weapons] 

d.  SPO  is  not  motivated  toward  economical  support 

AFLC  needs  veto  power  over  design  decisions 

Similarities  among  aircraft  avionics  are  greater  than  differences. 

e.  Analysis  and  design  and  testing  overwhelms  compilation/assembly. 

f.  Support  personnel  cost  more  than  development  personnel 

(Need  system  knowledge.  Implies  experience.) 

Autonetics  -  $65K/man  year 
GD  -  $35K/man  year 
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APPENDIX  E 


F-16/00ALC  DETAILED  DATA 
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PREDICTIVE  SOFTWARE  COST  MODEL 
FIELD  EVALUATION  REPORT 


GENERAL  SOFTWARE  PACKAGE  DESCRIPTION _ _ DATE:  31  Qct. 

ALC:  Qgden  (Hill  AFB)  |  WEAPON  SYSTEM:  _ 

SOFTWARE  PACKAGE:  f-16  OFPs  -  see  page  E-2. _ 

PERSONNEL  CONTACTED: 

Mr.  Have  Thomell/Mr.  Lee  Calvert  -  MMECA 
Captain  Michael  Fick/Mr,  Robert  Anderak  —  MMETA 
Mr.  Roy  Taketa/Mr.  Vernon  Duncan  —  ACDCS 
Mr.  Wayne  Bates  -  MMARF 

SOFTWARE  PACKAGE  CHARACTERISTICS:  Summary  -  See  pp.  E-2  through  E-6  for  overall 
description,  pp.  E-7  through  E-16  for  details. 

SIZE:  121K  (typical  size  is  12K  for  NAV/Display,  32K  for  Radar/Fire 

Ctl.) 

LANGUAGE:  Jovial  (J3B-2)  HOL  and  computer-unique  assembly  language 


APPLICATION: 


complexity:  Varies  from  low  to  high  —  see  quality  ratings  on  pp.  E-8,  10,  12, 

14,  16 

YEAR  DEVELOPED:  1976-1979 

developer:  See  individual  OFP  summaries 

comments  The  Fire  Control  Computer  OFP  is  representative  of  the  F-16 

system.  All  OFPs  and  00-ALC  operations  are  summarized  in  this 
package. 

HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS:  See  pp.  E-7  through  E-16  for  summary  and 

comments  on  individual  OFPs . 

MANUFACTURER: 

MODEL  number/designator  ■ 

WORD  SIZE: 

MEMORY  SIZE: 

MEMORY  FILL: 


Fire  Control  (FCC),  Navigation  (INS),  Displays  (HUD),  Radar, 
and  (armament)  Stores  Management  (SMS) 


WEAPON  SYSTEM  USE: 

NUMBER  OF  USERS:  USAF  -  Tactical  Air  Command  and  European  Participating 

Governments  (EPG) 

LOCATIONS  OF  USERS  US/Worldwide  and  EPG:  Belgium,  Denmark,  the  Netherlands, 
and  Norway 


FREQUENCY  OF  USE:  Daily 


INTERVIEWER(S):  R.  B.  Waina,  E.  E.  Rodriguez,  A.  P.  Bangs 


fRSCEDUO  FAGS  BLANK-NO*  FILMED 
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PREDICTIVE  SOFTWARE  C08T  MODEL 


CONTINUATION  SHEET  _  _ DATE:  31  Octobor  1979 


F-16  Avionics/OFPs 

Package  Summary 

The  F-16  avionics  is  supported  by  seven  coraputer/operational  flight  program 
(software)  subsystems.  This  package  summarizes  the  individual  OFP  character¬ 
istics  and  includes  organizational,  test,  support  software,  and  facility  data 
for  the  entire  r-16  00-ALC  support.  The  Fire  Control  Computer  (FCC)  OFP  is 
considered  a  representative  OFP.  OFP  change  history  is  presented  for  the  five 
OFPs  expected  to  be  maintained  by  00-ALC  organically  after  PMRT  (e.g.,  FCC,  INS, 
HUD,  RFC,  and  SMS).  Change  history  currently  reflects  contractor-initiated 
changes  with  verification  and  simulation  testing  by  MMECA,  avionics  and  simula¬ 
tor  testing/flight  testing  by  MMETA. 

A  summary  of  the  multiplex  F-16  avionics,  taken  from  the  Computer  Resources 
Integrated  Support  Plan  (CRISP)  is  included  below  with  detailed  FCC  function 
block  diagrams. 

Multiplex  System 

Digital  communication  among  F-16  avionic  subsystems  is  accomplished  over  a 
uually  redundant,  MIL- STD-1553  multiplex  system.  In  this  type  of  system,  data 
is  transmitted  at  a  one  megahertz  bit  rate  over  half-duplex  channels  using  a 
command/response  control  scheme.  Waveforms,  timing  and  word/message  formats  are 
as  prescribed  in  MIL-STD-L553.  Data  may  be  transmitted  either  between  a  bus 
controller  and  a  remote  terminal  or  between  two  remote  terminals.  A  diagram  of 
the  F-16  avionic  multiplex  system  is  presented  in  Figure  E-l.  The  primary 
control  of  the  multiplex  system  operations  Is  performed  by  the  bus  control 
function  in  the  Fire  Control  Computer  through  a  hardware  bus  controller  that 
operates  on  software  commands  stored  in  the  computer  memory.  This  bus 
controller  initiates  all  information  exchanges  over  the  data  buses  by  issuing 
command  words  to  remote  terminals  to  transmit  or  receive  data  and  determines 
whether  Bus  A  or  Bus  B  is  to  be  used  for  the  transmission.  A  backup  bus  control 
function  is  provided  by  the  Inertial  Navigation  System  (INS).  If  the  Fire 
Control  Computer  is  turned  off  or  fails  to  pass  its  self-test/built- in-test, 
a  discrete  signal  to  the  INS  is  turned  off  to  indicate  that  the  navigation  set 
is  to  assume  control.  Under  these  conditions,  the  INS  indicates  all  information 
exchanges  over  the  bus  and  selects  the  bus  to  be  used. 

FCC  Operational  Flight  Program 

The  Fire  Control  Computer  Operational  Flight  Program  (FCC  OFP)  provides 
logic  and  computations  to  implement  and  integrate  fire  control  system  modes 
and  functions.  The  OFP  consists  of  computer  processing  instructions  which 
have  been  developed  to  satisfy  allocated  avionics  requirements.  Because  of  its 
central  role  in  integrating  F-16  sensors  and  equipment  into  the  desired  fire 
control  system,  the  OFP  is  designated  a  configuration  item  and  has  accordingly 
had  requirements  for  configuration  management  in  accordance  with  MIL-STD-483  and 
the  configuration  management  plan  16PP153.  The  Fire  Control  Subsystem  is 
diagrammed  in  Figure  E-2, 
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PREDICTIVE  SOFTWARE  COST  MOO  EL 


CONTINUATION  SHEET 


DATE:  31  October  1979 


The  FCC  OFP  is  a  real-time  program  which  coordinates  sensor  and  equipment 
data  transfers  over  the  serial  digital  multiplex  data  bus  and  schedules  various 
processing  activities  to  implement  the  fire  control  and  navigation  modes 
selected  by  the  pilot.  The  functional  data  flow  relating  the  OFP  functions 
to  each  other  and  to  external  elements  is  shown  in  Figure  E-3. 


Most  of  the  processing  instructions  which  comprise  the  OFP  are  written 
in  the  J3B-2  high-order  language  (HOL)  to  support  advanced  concepts  of  software 
documentation,  understanding,  and  maintainability.  Use  of  J3B-2  HOL  also 
facilitates  modular  design  and  testing.  In  the  design  process,  each  functional 
requirement  is  mapped  into  one  or  more  OFP  components  for  implementation.  The 
definition  of  components  is  accomplished  through  the  top-down,  structured 
programming  methodology,  which  results  in  a  linear,  modular  program  with  readily 
identifiable  hierarchical  levels  and  single  entry  and  exit  points  for  each 
module.  As  a  result,  the  OFP  can  be  easily  read  and  tested,  and  revisions  to 
the  OFP  can  be  readily  undertaken  and  accomplished. 

Contractual  specifications  provide  for  30  percent  memory  and  40  percent 
speed  reserves  in  the  FCC  OFP  system,  with  currently  specified  requirements 
for  the  system.  Additional  detailed  data  on  the  requirements  this  program  and 
their  implementation  may  be  found  in  the  development  and  product  specification 
documents,  16ZE011-1  and  16AE011-2. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE: 


.  31  October  19  ? 9 
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Figure  E-l.  F-16  Avionic  Multiplex  System 


PREDICTIVE  SOFTWARE  COST  MOOEL 


DATE:  31  October  1979 


PREDICTIVE  SOFTWARE  COST  MODEL 

SOFTWARE  PACKAGE  CHARACTERISTICS  - _  DATE:  31  October  1979 

SOFTWARE  PACKAGE:  F-16  Fire  Control  Computer  (FCC) 

PERSONNEL  CONTACTED: 

Jim  Oldham  —  MMECA  Lead  Engineer 


SOFTWARE  PACKAGE  CHARACTERISTICS: 


SIZE: 

32,768  words 

LANGUAGE: 

JOVIAL  J3B-2  HOL  and  MAGIC  F-2  Assembly 

APPLICATION: 

Air-Air /Air-Gnd.  Fire  Control,  Data/Displays,  Store  Select, 
HUD,  NAV  Support,  Mission  Planning,  Fixtaking 

COMPLEXITY: 

Average  —  See  also  quality  ratings 

YEAR  DEVELOPED: 

1975-1976 

DEVELOPER: 

General  Dynamics 

COMMENTS 

JOVIAL/MAGIC/ML  Cross  Compiler  by  Softech 

MOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS: 

manufacturer.-  Delco  Electronics 

MOOEL  NUMBER/DESIGNATOR:  MAGIC  362  F-2 

WORD  SIZE:  16  and  32-Bit  instructions;  16  and  32-Bit  Fix.  Pt.  Data; 

24  and  48-Bit  Float  Pt.  Data 

MEMORY  SIZE:  MAIN  -  32K  (K  =  1024)  -  16  Bit  Word  Storage 

CPU  —  lK-40-Bit  microprogram  ROM 
memory  FILL:  26,542  (80  percent) 

—  85  percent  is  JOVIAL  developed;  15  percent  is 
direct  AL 


COMMENTS:  FCC  Specifications; 

Requirements  (B5)  —  No.  16ZE011-1D 

Design  (C5)  -  No.  16ZE011-2C 

User  Manual  -  No.  16PR249B 

All  Block  II  Changes  are  JOVIAL  implemented 

Analysis  is  80  percent;  Implementation  is  20  percent 
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PREDICTIVE  SOFTWARE  COST  MOO  EL 
CONTINUATION  SHEET  Quality  Ratings,  FCC  OFP 


OATE:  31  October  1979 


Accessibility:  8 

Instrumentation:  7 

Accountability:  7 

Interoperability:  1 

Access  Audit:  1 

Integrity:  8 

Access  Control:  8 

Legibility:  7 

Accuracy:  7 

Maintainability:  8 

Augmentability :  8 

Modifiability:  8 

Clarity:  9 

Modularity:  8 

Communicativeness:  7 

Operability:  7 

Communications,  Commonality:  6 

Performance:  8 

Completeness:  9 

Portability:  1 

Conciseness:  9 

Reliability:  8 

Consistency: 

Robustness:  1 

Internal  Consistency:  8 

External  Consistency:  7 

Correctness:  8 

Data  Commonality:  8 

Efficiency:  8 

Execution  Efficiency:  6 

Reusability:  3 

Selfcontainedness :  8 

Selfdescriptiveness:  7 

Simplicity:  6 

Structuredness;  8 

Storage  Efficiency:  7 

Testability:  7 

Error  Tolerance:  9 

Traceability:  8 

Expandability:  8 

Training:  7 

Generality:  7 

Understandability :  8 

Human  Engineering:  7 

Independence: 

Device :  1 

Software  System:  1 

Usability  (as-is  utility) ;  7 

_ _ i 
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PREDICTIVE  SOFTWARE  COST  MODEL 
SOFTWARE  PACKAGE  CHARACTERISTICS  - _ 


DATE:  31  October  1979 


SOFTWARE  PACKAGE:  F-16  Inertial  Navigation  Set  (INS) 


PERSONNEL  CONTACTED: 

Paul  Reimann  —  MMECA  Lead  Engineer 


SOFTWARE  PACKAGE  CHARACTERISTICS-’ 

SIZE:  PROM/ROM/RAM:  9194  (Max.  is  11,776  words  for  existing  memory  cards) 

LANGUAGE:  SKC-3000  Assembly  Language 

application:  Inertial  Navigation  Unit  —  Navigation  Panel  Display, 

Back-up  bus  control  for  all  OFPs  if  FCC  inoperative. 

complexity-.  Low  to  moderate  —  see  also  quality  ratings 

year  developed:  Version  2.03  release  date  —  August  1976 

Version  2.06  release  date  —  December  1977 


DEVELOPER: 


COMMENTS 


Singer  Kearfott  Division  (SKD),  Wayne,  N.J. 
Instruction  set,  constants  are  in  firmware  —  PROM/ ROM 


HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS: 

MANUFACTURER:  Singer  Kearfott 

MODEL  NUMBER/DESIGNATOR:  SKC-3000 

Instruction  Data 


WORD  SIZE: 


MEMORY  SIZE: 


15  bit  ROM 
7168 


19  bit 
RAM  &  ROM 


2048 


MUX  Variable 
16  hit  RAM 


2048 


Senal  Core 
I/O  Variable 


I/O  Channel 


19  hit  core  jo  hit 


64 


448 


24  5* 


MEMORY  FILL:  **  6685  (93%)  1487  (73%)  *32  (4 0.6"')  64  (100%) 

*Listed  is  program  size.  Total  physical  memory  except  core  and  I/O  is  32K. 

Thus  fill  is  28%  H/W;  81.6%  of  maximum  OFP  S/W. 

**Besides  6685  Instruction  words,  another  102  15-blt  instruction  words  used  as 
data  constants  (95"'  total);  512  (50%)  of  1048  19-bit  RAM  (volatile)  data  memory 
and  975  (95%)  of  bit  ROM  data  constants  are  used  up. 

COfjMEMTS :  The  INS  OFP  is  contractor  supported  until  (at  least)  1983  by  a  Reliability 

Improvement  Warranty  (RIW) .  Changes  are  by  subcontractor,  Singer-Kearfott  (SKD) 
manufacturing  change  of  the  ROM  chips.  Due  to  expected  infrequenct  OFP 
changes,  complete  program  verification  is  tested  with  a  SKD  test  stand.  00-ALC 
tests  consist  of  Interpretive  Computer  Simulation  (small  portions  of  the  OFP), 
post-processing  scaling  and  inspection,  inter-OFP  communications  test  in  the 
Avionics  Equipment  Bay  (AEB)  by  MMETA,  and  flight  tests. 
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QATE:  31  October  1979 


PREDICTIVE  SOFTWARE  COST  MODEL 
CONTINUATION  SHEET  Quality  Ratings,  INS  OFP _ 


Accessibility:  2 

Instrumentation:  2 

Accountability:  2 

Interoperability:  7 

Access  Audit:  1 

Integrity:  8 

Access  Control:  5 

Legibility:  4 

Accuracy :  8 

Maintainability:  4 

Augment ability:  4 

Modifiability:  4 

Clarity:  4 

Modularity:  6 

Communicativeness:  7 

Operability:  5 

Communications,  Commonality:  3 

Performance:  3 

Completeness :  9 

Portability:  1 

Conciseness:  9 

Reliability:  8 

Consistency: 

Robustness:  5 

Internal  Consistency:  6 
External  Consistency:  7 

Correctness:  8 

Data  Commonality:  6 

Efficiency: 

Execution  Efficiency:  8 

Reusability:  2 

Self containedness :  9 

Self descriptiveness :  4 

Simplicity:  3 

Structuredness:  6 

Storage  Efficiency:  9 

Testability:  4 

Error  Tolerance:  5 

Traceability:  7 

Expandability:  4 

Training:  3 

Generality:  3 

Understandability:  4 

Human  Engineering:  6 

Independence: 

Device:  1 

Software  System:  1 

Usability  (as-is  utility):  5 
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PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  - _ DATE:  31  October  1979 

SOFTWARE  PACKAGE:  p-16  Head-Up  Display  (HUD)  | 

PERSONNEL  CONTACTED: 

Lowell  Weed  —  MMECA  Lead  Engineer 


J  SOFTWARE  PACKAGE  CHARACTERISTICS: 

Block  (Issue)  I  -  7168;  Block  II  -  11264  words 

Assembly  (Marconi  Specialized) 

Disnlavs  with  snanshoot  ounnerv.  Hackuo  missile  launch.  T COS  &  IL! 
flight  director  functions 

Not  rated  (by  ALC)  -  see  also  quality  ratings. 

1976 

Marconi-Elliot  Avionic  Systems,  Ltd.,  England 

The  wrD  operational  flight  program  was  developed  first  as  a  two 
level  (PT,OCv  I)  and  then  as  a  three  level  (B1  o1”'  II)  program. 

HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS: 

manufacturer:  Marconi  General  Dynamics 

MODEL  NUMBER/DESIGNATOR:  GD  P/N  16VE017003 
WORD  SIZE:  16-bit 

MEMORY  SIZE:  Block  I  -  8K;  Block  II  -  16K 

memory  fill;  Block  1-88  percent;  Block  II  -  70  percent 


COMMENTS: 

The  HUD,  Central  Air  Data  Computer  (CADC)  and  RADAR-EO  Display  were  originally  one 
configuration  item.  The  CADC  and  REO  OFPs  are  low  frequency  change  CPCIs  not  to  be 
maintained  by  ALC.  Originally  HUD  was  a  ROM,  since  changed  to  EPROM.  Although  not 
a  PSCM  OFP  package  item,  OFP  and  support  software  data  for  CADC  and  REO  are  attached 
for  reference. 


SIZE: 

LANGUAGE: 

APPLICATION: 

COMPLEXITY: 

YEAR  DEVELOPED: 

OEVELOPER: 

COMMENTS 
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PREDICTIVE  SOFTWARE  COST  MODEL 


OATE:  31  October  1979 


Accessibility:  1 

Instrumentation:  7 

Accountability:  3 

Interoperability:  9 

Access  Audit:  1 

Integrity:  10 

Access  Control:  3 

Legibility:  7 

Accuracy:  9 

Maintainability:  7 

Augmentability :  5 

Modifiability:  8 

Clarity:  6 

Modularity:  3 

Communicativeness:  7 

Operability:  8 

Communications,  Commonality:  2 

Performance:  8 

Completeness:  8 

Portability:  1 

Conciseness:  9 

Reliability:  8 

Consistency: 

Robustness:  1 

Internal  Consistency:  7 

Reusability:  4 

External  Consistency:  8 

Self containedness :  8 

Correctness:  9 

Selfdescriptiveness:  8 

Data  Commonality:  7 

Simplicity:  7 

Efficiency: 

Structuredness:  6 

Execution  Efficiency:  9 

Storage  Efficiency:  8 

Testability:  6 

Error  Tolerance:  2 

Training:  5 

Expandability:  7 

Training:  5 

Generality:  2 

Understandability :  5 

Human  Engineering:  9 

Usability  (as-is  utility):  7 

Independence : 

Device:  1 

Software  System:  1 
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PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  -  DATE:  31  October  1979 

- 1 

SOFTWARE  PACKAGE:  F"16  Fire  Control  Radar  (FCR)  J 

PERSONNEL  CONTACTED;  ~~~  ”  ~  ~ i 

Dave  Erickson  -  MMECA  Lead  Engineer 


!  SOFTWARE  PACKAGE  CHARACTERISTICS: 


SIZE: 

Current:  EPROM  -  32768  ECP116: 

RAM  -  4096 

EPROM  -  49152 
RAM  -  16384 

words 

LANGUAGE: 

Assembly 

APPLICATION: 

Air-air  search,  acquisition,  and  target  tracking; 
air-ground  ranging,  and  processing. 

ground  mapping. 

COMPLEXITY: 

Very  -  see  also  quality  ratings. 

YEAR  DEVELOPED: 

1976-1979;  ECP  update  1979-1980 

DEVELOPER: 

Westinghouse  Electric  Corporation 

COMMENTS 

HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS: 

MANUFACTURER:  WeStinghouSe 

MODEL  NUMBER/DESIGNATOR:  - 
WORD  SIZE:  16-BitS 

MEMORY  SIZE:  32K  EPROM, 4K  TAM  will  be  48F  EPPOM,  16K  RAM 

memory  FILL:  100  percent;  will  have  a  12^  FPP0M  reserve 


COMMENTS: 

Although  design  is  structured  (29  functional  task)  module,  programming  is  not 
except  for  top  level  flow  chart  branching.  Local  and  global  labels  have  common 
alphanumer ics  for  related  functions. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  Quality  Ratings,  FCR  OFP 


31  October 


Rate  the  Package  on  the  following  Quality  attributes: 


Accessibility;  8 
Accountability:  5 

Access  Audit:  2 

Access  Control:  2 
Accuracy:  8 

Augment ability:  4 

Clarity:  4 

Communicativeness:  8 

Communications ,  Commonality : 
Completeness:  5 
Conciseness:  8 
Consistency: 

Internal  Consistency:  7 
External  Consistency:  7 

Correctness:  5 

Data  Commonality:  8 

Efficiency: 

Execution  Efficiency:  6 
Storage  Efficiency:  6 

Error  Tolerance:  6 

Expandability:  3 

Generality:  7 

Human  Engineering:  5 

Independence: 

Device:  1 

Software  System:  1* 


Instrumentation:  8 
Interoperability:  6 

Integrity:  1 

Legibility:  3 

Maintainability:  7 

Modifiability:  5 

Modularity:  5 

Operability:  7 

Performance:  .3 

Portability:  1 < 

Reliability:  8 

Robustness:  3 

Reusability:  T 

Selfcontainedness:  3 

Selfdescriptiveness:  8 
Simplicity:  3 

Structuredness:  ^ 

Testability:  7 

Traceability:  7 

Training:  7 

Understandability:  3 
Usability  (as-is  utility):  6 


328 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  - _ pATE:  31  October  1979 

SOFTWARE  PACKAGE:  F-16  Stores  Management  System  (SMS) 

PERSONNEL  CONTACTED:  ~ 

Darwin  Jensen  -  MMECA  Lead  Engineer 


SOFTWARE  PACKAGE  CHARACTERISTICS: 


SIZE: 

LANGUAGE: 

APPLICATION: 

COMPLEXITY. 

YEAR  DEVELOPED: 

DEVELOPER: 

COMMENTS 


34816  words 
Assembly 

Monitor  status,  Control,  and  release  of  armament 
High  -  see  also  quality  ratings 


1 


(stores) 


1978 


General  Dynamics 


HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS: 


manufacturer:  General  Dynamics 

MODEL  NUMBER/DESIGNATOR:  8080 

WORD  SIZE:  8-BitS 

MEMORY  SIZE:  36864 

MEMORY  FILL:  94% 


COMMENTS:  Programs  permits  ground  or  airborne  mission  allocation,  multiple 

options  on  delivery/selection,  arming,  and  release.  Each  store  has  pre¬ 
determined  options  and  has  target  type  (eg-TANK)  association  for 
operation  selection.  SMS  computer  has  a  primary  and  second  (backup) 
microprocessor.  ALC  engineers  have  two  years  experience  with  2-3  weeks 
microprocessor  AL/ML  and  system  specialized  training. 


PREDICTIVE  SOFTWARE  CQ8T  MODEL 


CONTINUATION  SHEET  Quality  Ratings,  SMS  OFP _ OATE:31 

Accessibility:  9 
Accountability : 

Access  Audit:  1 


Access  Control:  1 
Accuracy:  9 
Augmentability :  2 

Clarity:  3 
Communicativeness:  7 
Communications,  Commonality:  8 
Completeness:  6 
Conciseness:  3 
Consistency: 

Internal  Consistency:  9 
External  Consistency:  6 

Correctness:  9 

Data  Commonality:  10 

Efficiency: 

Execution  Efficiency:  9 
Storage  Efficiency:  5 

Error  Tolerance:  3 

Expandability:  2 

Genrality:  5 

Human  Engineering:  9 

Independence: 

Device:  6 

Software  System:  6 


Instrumentation:  A 
Interoperability:  8 
Integrity:  9 
Legibility:  2 
Maintainability:  1 
Modifiability:  2 
Modularity:  8 
Operability:  8 
Performance:  8 
Portability:  9 
Reliability:  10 
Robustness:  10 
Reusability:  1 
Selfcontainedness:  10 
Self descriptiveness :  2 

Simplicity:  1 
Structuredness:  A 
Testability:  1 
Traceability:  A 
Training:  2 

Understandabilit^:  2 
Usability  (as-is  utility):  3 


PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  PERSONNEL 


KEY  PERSONNEL/OGRANIZATION: 


DATE:  31  October  1979 


OFFICE  SYMBOL:  OOALC/MMECA 


Dave  Thornell 
Mike  Welch 
Capt.  Fick 
Bob  Anderak 
Verlon  Duncan 
Roy  Taketa 
Wayne  Bates 
Lee  Calvert 


-  MMECA  (801)  777-7231 

-  MMECA/F-16 

-  MMETA  (801)  777-1211 

-  MMETA/ F- 16 

-  ACDCS  (801)  777-7522 

-  ACDCS  (801)  7^7-6161 

-  MMARE  (801)  777-5871 

-  MMECA 


Section  Chief 

Lead  OFP  Engineer 

AISF  &  Flight  Test  Interface 


Configuration  Control 
Change  Control 


Figure  E-4  on  page  E-18  provides  an  organization  chart. 


TOTAL  ASSIGNED  PERSONNEL  (NUMBER  &  TYPE):  (all  civil  service/military) 


MMECA  -  33 

MMETA  -  15  (projected) 
ACDCF  -  39  (planned) 


TOTAL  PACKAGES  MAINTAINED  (NUMBER  &  TYPE): 

F-16  -  7  OFPs 
F-4  -  2  OFPs 

plus  support  software 


PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  WORK  DISTRIBUTION _ DATE:  31  October  1979 

DESCRIPTION  OF  WORK  PACKAGE  DISTRIBUTION,  INCLUDING  RESPONSIBILITIES  AND  DEGREE  OF 
SPECIALIZATION  OF  AF/CS/CONTR  PERSONNEL 

MMECA  has  (i.e.,  will  have  after  PMRT)  responsibility  for  software  engineering  on 
the  F-4  and  F-16.  MMETA  provides  independent  validation  and  verification  (both 
ground  simulation  and  flight  testing)  of  software  changes,  and  also  provides 
AISF  services  to  MMECA.  ACDCS  (comptroller)  provides  programming  support  for  the 
support  software  (both  AISF  and  General  Purpose  Computer  Complex).  ACDCS  personnel 
essentially  work  for  MMECA.  MMARE  provides  acquisition  support,  controls  the 
F-16  budget,  and  currently  provides  three  engineers  which  MMETA  would  normally 
have.  This  arrangement  is  due  to  local  manpower  restrictions. 


Organization 

Total 

F-16 

F-4 

Flight  Test 

MMECA1 

2 

33 

15  — «* - 

- ►  17 

7 

MMETA 

15' 

7 

3 

4 

ACDCS: 

394 

AISF 

9 

14 

GPCC 

_8 

_8 

_ 

872 3 

39 

42 

4 

1.  Personnel  shift  back  and  forth  in  response  to  workload  requirements. 

2.  Includes  section  chief. 

3.  Includes  section  chief. 

4.  Five  persons  shared  between  F-4/F-16. 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  -  WORK  DISTRIBUTION 


MMECA  assigned 

personnel: 

1 

GS-13 

Electronics 

Engineer 

(supervisory) 

25 

GS-12 

Electronics 

Engineer 

(ECS) 

2 

GS-ll 

Electronics 

Engineer 

1 

GS-9 

Electronics 

Engineer 

2 

1-Lt 

Electronics 

Engineer 

2 

GS-4 

Clerk 

ACDCS  assigned  personnel  (planned)  : 

1  GS-13  Supervisor 

15  GS-12  Lead  Engineer 

19  GS-ll  Analysts  and  Programmers 

1  GS-07  Configuration  Management 

3  GS-05  Steno/Computer  Aide/Technician 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  -  WORK  DISTRIBUTION 
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PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  COST  ACCOUNTING  SYSTEM 


DATE: 


Cost  accounting  tracks  all  activities  directly  associated  with  OFP  maintenance  and 
support.  Documentation  is  via  the  Project  Accounting  and  Control  System.  Sample 
reports  are  shown  on  pp.  E-23  and  E-24. 


PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES _ DATE:3*  October  1979 

SUPPORT  PHILOSOPHY: 

PMRT  for  the  F-16  aircraft  is  scheduled  for  1985.  However,  00-ALC  will  assume 
responsibility  for  software  engineering  in  1981  as  originally  planned.  MMECA 
currently  provides  validation  and  verification  (V&V)  services  to  the  SPO  for 
contractor-supplied  OFPs  and  updates.  Also  included  are  AISF* integration  and  test, 
and  flight  test.  Post-PMRT  will  be  guided  by  the  Material  Improvement  Project 
(M1P)  which  provides  problem/management  control  for  all  change  tracking  and 
documentation  of  OFP  O&M  activity.  Pages  E-26  through  E-29,  extracted  from  the 
F-16  avionics  Computer  Resources  Integrated  Support  Plan,  describe  the  overall 
support  plan. 


*See  Glossary  on  pp.  E-72ff  for  acronyms. 


CHANGE  CONTROL  METHODS: 

FORMAL  OR  INFORMAL:  Currently  informal;  a  formal  tracking  system  is 

being  established.  Approval  authorities  are 
described  on  pages  E-30  through  E-33. 

CHANGE  REVIEW  PROCESS: 

The  process  is  documented  in  "F-16  Operational/Support  Conf iguration 
Management  Procedures"  dated  2  July  1979.  A  formal  baseline  will  be 
established  at  PMRT  based  on  the  turn-over  Version  Description  Documents. 
The  change  process  is  described  on  pp.  E-34  through  E-38. 


CONFIGURATION  IDENTIFICATION  METHODS: 

Computer  Program  Identification  Numbers  -  see  pp.  E— 39  through  E-41, 

CONFIGURATION  CHANGE  CONTROL  METHODS. 

See  pages  E-39  through  E-41, 


CONFIGURATION  STATUS  ACCOUNTING  METHODS: 

See  page  E-42. 

SOFTWARE  LIBRARY  CONTROL  PROCEDURES: 

Support  software  is  under  ACDCS  control;  master  tape  and  working  tapes 
under  MMETA  (AISF)  control  with  central  and  remote  tape  vaults. 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  -  SUPPORT  PHILOSOPHY _  DATE^1  October  1979 


PRE-PMRT  Program  Management 

The  Implementing  command,  AFSC,  has  total  management  responsibility  from 
the  Conceptual  through  Full  Scale  Development  Phases  until  the  system  turnover 
milestone.  At  system  turnover,  the  configuration  baseline  will  have  been 
established. 

System/ equipment  turnover  will  be  accomplished  in  accordance  with  the  F-16 
System/ Equipment  Turnover  Plan.  From  system  turnover  until  PMRT,  AFSC  retains 
overall  program  management  responsibility  and  is  the  final  approval  authority 
for  all  system  changes. 

OFP  Changes 

The  change  process  used  by  the  SPO  during  Full  Scale  Development  will  be 
continued  through  to  PMRT.  Changes  to  F-16  computer  programs  will  be  considered 
Class  I  and  will  be  processed  as  Class  I  ECPs  IAW  the  F-16  SPO  procedures. 

AFLC/User  Participation 

Eventual  transition  of  an  F-16  OFP  support  posture  as  outlined  by  the  CRISP 
requires  participation  by  AFLC  and  F-16  user  organizations  in  Full  Scale  Develop¬ 
ment  and  Production  activities.  Where  participation  is  such  a  nature  that  is 
not  normally  covered  within  existing  plans  and  MOAS,  separate  agreements  will  be 
established  between  the  involved  organizations;  the  degree  of  participation, 
location  of  the  activity  and  resources  will  be  negotiated  thereunder.  However, 
these  agreements  will  not  jeopardize  the  responsibilities  of  the  contractor  in 
obtaining  formal  Air  Force  acceptance  of  the  approved  production  OFP  baseline. 

An  agreement  will  be  developed  to  delineate  the  working  arrangements  to  be 
utilized  in  phasing  in  AFLC  organic  OFP  support.  The  concept  to  be  employed 
will  be  single  point  responsibility  for  technical  and  engineering  aspects  of 
software  modifications. 

Prior  to  PMRT,  emphasis  will  be  placed  on  useability  at  the  operational 
site  and  supportability  planned  by  AFLC.  In  all  cases,  the  SPO  will  make  the 
final  decision  regarding  the  extent  of  Ogden  ALC  software  support  to  the  FSD 
and  Production  contracts. 

Post- PMRT  Program  Management 

At  PMRT,  the  F-16  Multinational  Configuration  Control  Board  (MCCB)  will 
transfer  to  Ogden  ALC.  EPG  and  user  representation  to  the  F-16  MCCB  will  be 
retained.  The  F-16  MCCB,  under  the  authority  of  the  Ogden  ALC  CCB  Chairman, 
will  consider,  evaluate  and  make  decisions  on  behalf  of  the  involved  parties 
with  respect  to  Engineering  Change  Proposals  (ECPs)  that  impact  the  F-16  weapon 
system. 

The  CRISP  assumes  that  a  Multinational  CPCSB  will  be  established  under  the 
MCCB  to  centralize  the  control  of  F-16  OFP  software  changes  which  do  not  affect 
system  equipment. 
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PREDICTIVE  SOFTWARE  COST  MODEL 

CONTINUATION  SHEET  -  SUPPORT  PHILOSOPHY _ DATE:  31  October  1979 

OFP  Changes 

For  planning  purposes,  organic  OFP  update  block' changes  will  be  scheduled 
approximately  once  per  year.  However,  user  priorities  and  projected  AFLC 
workload  may  affect  the  detailed  scheduling,  as  well  as  the  anticipated  time 
span  to  retrofit  released  OFP  updates. 

F-16  MCCB  approval  will  be  required  for  organic  updates  affecting  both 
software  and  hardware.  Additionally,  MCCB  approval  will  be  required  for 
contractor  ECPs  addressing  software  and/or  hardware  impacts  related  to  the 
F-16  production  program.  When  the  proposed  modifications  are  approved,  the 
changes  will  be  implemented  in  accordance  with  the  applicable  AFLC  procedures. 

Production  Interface 

Until  production  of  the  F-16  aircraft  ceases,  Ogden  ALC  must  assure  the 
F-16  AISF  equipment  and  software  reflect  current  configurations  of  the  F-16 
system.  Additionally,  Ogden  ALC  must  assure  that  production  impacts  are 
adequately  addressed  for  any  proposed  OFP  updates. 

Retrofit 

It  is  planned  that  the  FCC  OFP  update  will  be  released  as  a  field  level 
TCTO.  Each  user  will  requisition  the  required  number  of  kits  once  the  block 
change  is  released  and  will  schedule  their  retrofit  based  on  their  retrofit 
implementation  planning. 

Conceptually,  the  AIS  data  file  will  be  updated  with  the  new  release  of 
the  FCC  OFP.  Then  the  FCC  will  be  cycled  through  maintenance  to  reload  the  FCC 
with  the  updated  OFP. 

Reprogrammable  firmware  retrofit  concepts  are  under  review  to  assess  con¬ 
figuration  management  and  logistics  impacts.  In  October,  1978,  the  F-16 
program  initiated  action  to  obtain  an  intermediate  level  retrofit  capability 
for  the  memory  contents  of  the  Central  Interface  Unit  (CIU)  and  the  Radar 
Computer.  The  concept  is  to  obtain  a  self-contained  piece  of  support  equipment 
designed  to  reprogram  and  verify  the  firmware  (EPROMs)  in  an  intermediate  level 
environment.  Firmware  (PROM)  retrofit  is  not  contemplated  at  the  intermediate 
level  due  to  very  low  change  rates. 

Non-reprogrammable  firmware  (ROM)  and  reprogrammable  firmware  (PROM) 
retrofit  of  the  SRUs  at  the  depot  is  via  a  depot  level  TCTO.  The  retrofit  concept 
will  be  summarized  in  later  CRISP  updates  on  analyses  and  planning  by  the  F-16 
Maintenance  Engineering  Working  Group. 
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OFP  Block  Change  Cycle 

Reported  computer  program  deficiencies  and  new  capabilities  will  be 
forwarded  to  Ogden  ALC  for  review  and  evaluation.  As  shown  in  Figure  E-5, 
Preliminary  Engineering  Change  Proposal (s),  addressing  accumulated  OFP  Change 
requests,  will  be  reviewed  at  a  joint  technical  conference  attended  by  rep¬ 
resentatives  of  the  USAF/EPAF  users  and  chaired  by  F-16  System  Manager  (SM) 
representative. 


The  purpose  of  the  technical  conference  is  to  establish  priorities,  acquire 
user  approval  of  the  proposed  OFP  changes  and  revise  the  Preliminary  Engineering 
Change  Proposal(s).  This  conference  will  be  supported  by  data  from  feasibility 
studies  and  engineering  tests  conducted  to  better  define  the  requirements  and/or 
software  solution.  Following  approval  by  the  CPCSB/MCCB,  the  update  process 
will  proceed  through  the  engineering  development  and  test  cycles  as  shown  in 
Figure  E-5.  At  each  major  design  review  (PDR,  CDR) ,  the  option  exists  to  transfer 
selected  change  candidates  to  the  next  OFP  block  change  as  negotiated  by  the 
F-16  SM  and  the  USAF/EPAF  user  and  approved  by  the  CPCSB/MCCB.  For  planning 
purposes,  the  joint  technical  conference  will  effectively  constitute  a  System 
Design  Review  (SDR)  unless  the  CPCSB/MCCB  directive  stipulates  a  need  for  a 
follow-on  SDR. 

Review  of  the  OFP  update  will  be  conducted  in  accordance  with  MIL-STD-3 521. 
The  documentation  will  be  produced  and  maintained  in  accordance  with  MIL-STD-483 
and  490.  Additionally,  the  approved  Preliminary  ECP(s)  establishes  the  new 
functional  baseline. 


The  PDR  will  be  heid  to  review  the  preliminary  design  approach  and  the 
computer  program  development  specifications.  The  review  must  (1)  result  in 
concurrence  on  the  acceptability  of  the  engineering  approach  and  follow-on 
effort,  (2)  provide  formal  approval  of  the  computer  program  development 
specifications,  and  (3)  give  approval  to  proceed  with  detailed  design. 
Additionally,  the  computer  program  development  specifications  are  placed  under 
configuration  control  so  that  any  further  changes  must  be  formally  approved. 
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Approval  Authority,  Boards  and  Committees  for  Computer  Program  Configurations: 

F-16  Air  Combat  Fighter  Configuration  Steering  Group  (F-16  ACF/CSG) .  The 
following  responsibilities  are  direct  extractions  from  the  CSG  Charter: 

The  CSG  acts  as  the  USAF  focal  point  for  review  and  control  of  the 
F-16  weapons  system  design  and  production  conf iguration(s) . 

The  group  members  are  AF/RD  (Chairman),  AF/XD,  AF/OF,  AF/RDP,  AF/RDQ, 
TAC/DR,  AFALD  and  AFSC/SD.  The  CSG  will  meet  when  called  by  the 
chairman.  Progress  reports  will  be  forwarded  to  AF/CC  as  required. 

A  termination  date  of  the  CSG  has  not  been  determined. 

Following  are  functions  of  the  CSG: 


a.  Review,  analyze  and  establish  the  basic  F-16  configuration. 

b.  Review,  analyze,  and  approve/disapprove  appropriate  change 
proposals  for  the  F-16,  based  on  their  effect  on  life  cycle 
cost,  schedule  and  performance. 

c.  Periodically  review  activities  of  the  F-16  Configuration 
Control  Board  in  managing  the  configuration  of  the  F-16  as 
prescribed  in  AFR  65-3. 

d.  Request  studies  or  reports  as  necessary  from  the  F-16  System 
Program  officer  and  other  organizations  to  insure  that  all 
requirements  and  configuration  changes  are  considered  in  the 
light  of  the  objective  of  minimizing  life  cycle  costs  while 
retaining  required  operational  performance  capabilities. 

Types  of  Change  Proposals  (CPs)  to  be  resolved  by  CSG  action  include: 

a.  Those  CPs  originating  external  (using/supporting  command  or 
allied  country)  to  the  F-16  Program  Office/Contractor,  and 
with  which  the  Program  Manager  (PM)  disagrees  (unless  the  CP 
is  withdrawn  by  the  originator) . 

b.  Those  CPs  having  a  Configuration  Control  Board  (CCB) 
minority  position,  which  is  supported  by  major  command 
deputate  level. 
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c.  Those  CPs  which  change  system  performance  capability  from 
validated  operational  requirements, 

d.  Those  CPs  which,  if  implemented,  will  be  likely  to  breach 
performance,  cost,  or  schedule  thresholds  documented  in 
the  PMD. 

e.  Those  CPs  requiring  resources  outside  of  the  allocated 
program  resources,  i.e.,  VECPs  and  CPs  requiring  now  dollars 
to  affect  life  cycle  cost  savings. 

f.  Those  CPs  which  the  PM  judges  to  be  of  interest  to  the  CSG. 

NOTE:  All  other  CP  activity  to  be  managed  in  accordance  with 
with  existing  regulations,  with  a  quarterly  summary 
report  to  the  CSG,  attendant  to,  but  separate  from,  the 
PAR/SPR. 

For  avionics  software,  the  CSG  shall  allocate  memory  and  timing 
reserves. 

Multinational  Configuration  Control  Board  (MCCB) : 

The  MCCB  is  established  by  the  Multinational  Memorandum  of 
Understanding  (MOU)  and  shall  be  a  governing  body  for  the 
lifetime  of  the  weapon  system.  Prior  to  PMRT,  the  System 
Program  Director  (ASD/YP) ,  is  the  chairman  of  the  MCCB  which 
acts  on  all  Engineering  Change  Proposals.  Representatives 
of  the  Five  Nations  and  TAC  sit  on  the  MCCB. 

After  PMRT,  one  representative  from  each  participating  government 
and  TAC  will  become  a  member  of  the  Ogden  ALC  Multinational 
Configuration  Control  Board  (MCCB),  on  F-16  matters.  The  MCCB, 
under  authority  of  the  Ogden  ALC  MCCB  Chairman,  will  consider, 
evaluate,  and  make  implementing  decisions  on  behalf  of  the 
involved  parties  with  respect  to  Engineering  Change  Proposals 
(ECPs)  presented  to  the  board.  In  general,  the  MCCB  shall  consider 
implementation  of  all  changes  to  the  F-16  weapon  system.  The 
authority /decision  to  approve  any  modifications  to  the  F-16 
weapon  system  will  remain  with  the  appropriate  government  offices. 

Computer  Program  Configuration  Sub-Board:  At  PMRT,  the  OO-ALC  MCCB 
will  establish  an  F-16  CPCSB  to  review  and  approve/disapprove  F-16 
weapon  system  software  change  requests. 
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The  CPCSB  will  include  representation  from  applicable  AFLC,  AFSE, 

TAC,  EPAF,  and  technical  coordinators  as  required.  Each  nation 
shall  have  one  voting  member.  The  F-16  System  Manager  (MMA)  will  be 
the  chairman  of  the  CPCSB.  This  CPCSB  shall  be  governed  by  OO-ALC 
Reg  XXXX.  The  significant  roles  of  the  multinational  CPCSB  are: 

a.  Approval/disapproval  authority  for  all  CPCI  Class  II  on-aircraft 
software  changes. 

b.  Approval/disapproval  authority  for  all  CPCI  Class  I  on-aircraft 
software  changes  which  do  not  affect  system  equipment  and  can 
be  accomplished  within  existing  AFLC/TAC/EPAF  resources. 

c.  Approval/disapproval  authority  of  companion  Class  I  and 
Class  II  software  changes  to  off-aircraft  computer  resources. 

d.  Approve /disapprove  emergency  software  change  requests/ECPS . 

e.  Recertify  and  reprioritize  outstanding  software  change  requests. 

f.  Approve/disapprove  UUT  test  program  CPCIs  changes. 

g.  Approve/disapprove  ECPs  for  AIS  control  and  support  software 

CPCI:  It  is  anticipated  that  minor  changes  to  electronic  warfare 

and  training  devices  may  be  accomplished  without  affecting  system 
integrity.  However,  if  recoupment  is  planned,  such  changes  will 
be  forwarded  to  F-16  MCCB  for  review/approval/disapproval. 

TAC  Software  Requirements  Review  (SRR) :  TAC  will  establish  an  SRR 
OPR  to  receive,  screen,  prioritize,  and  recertify  to  the  program 
manager  (SPO)/AFLC  SM  all  TAC  software  change  requests.  HQ  TAC/DR 
will  serve  as  chairman  fo  the  SRRB  and  will  be  the  single  point  of 
contact  for  all  TAC  F-16  weapon  system  software  changes.  The  chair¬ 
man  of  the  SRRB  will  be  appointed  as  command  representative  to  all 
joint  AFLC/TAC/EPAF  software  review  boards /committees  which  are 
established  to  perform  formal  design  reviews  and  to  monitor  approved 
software  change  requests. 

EPAF  Software  Requirements  Review  (SRR) :  Each  will  establish  an  SRR 
OPR  to  receive,  screen,  prioritize,  certify  and  submit  to  the  AFLC 
SM  all  software  change  requests.  The  following  EPAF  single  points  of 
contact  will  serve  as  the  chairman  of  their  respective  SRRB  and  focal 
point  for  software  change  requests: 
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a.  Belgium  -  The  software  support  cell  (VDT/B-5)  avionics 
section  at  BAF  airstaff  in  Brussels,  Belgium. 

b.  Norway  -  Royal  Norwegian  Air  Force  (RNoAF)  Materiel  Command 
at  Kjeller,  Norway. 

c.  Netherlands  -  The  F-16  Avionics  Section  at  the  Directorate  of 
Air  Materiel  in  THE  HAGUE  (DMKLU/AVL/VL2) . 

d.  Denmark  -  The  HQ  Tactical  Air  Command  Denmark  (TACDEN) , 

Karup  Air  Base. 
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Computer  Program  Configuration  Items 

Operational  Flight  Programs  (OFPs)  will  be  managed  as  Computer  Program 
Configuration  Items  (CPCIs).  Changes  to  baseline  CPCIs  which  are  proposed 
by  the  contractor  will  be  submitted  as  Class  I  Engineering  Change  Proposals 
(ECPs)  per  MIL-STD-480,  MIL-STD-481,  as  supplemented  by  MIL-STD-483,  Appendix 
XIV.  All  using  activity  proposed  engineering  changes  to  baseline  CPCIs  will 
be  submitted  per  AFR  57-4,  Retrofit  Configuration  Changes  procedures.  Prior 
to  PMRT ,  16PP153,  the  F-16  Configuration  Management  Plan  will  apply  to  config¬ 
uration  management  of  CPCIs. 

OFP  Configuration  Management  Approach 

The  purpose  of  this  section  is  to  present  the  planned  approach  for 
configuration  amangement  of  all  F-16  OFPs.  Configuration  management  for  the 
various  phases  of  the  F-16  life  cycle  will  differ.  Consequently,  this  section 
is  divided  into  three  phases:  developmental,  transitional,  and  operational. 

Developmental  Phase 

The  developmental  phase  is  that  period  of  time  beginning  with  the 
conception  of  the  system  and  ending  at  F-16  Air  Vehicle  Physical  Configuration 
Audit  (PCA) .  Software  configuration  management,  documentation,  reviews  and 
audits  for  both  operational  and  support  software  shall  be  developed  and 
conducted  in  accordance  with  the  guidance  provided  by  MIL-STDs-483 ,  490,  and  1521. 
The  product  baseline  will  be  established  after  completion  of  the  Air  Force  flight 
test  program  and  after  all  changes  required  for  acceptable  F-16  performance 
have  been  implemented,  verified,  and  documented.  Changes  to  CPCIs  will  be 
proposed,  formatted  and  processed  In  accordance  with  MIL-STD-483  (Appendix  XIV). 
Engineering  change  control  authority  is  the  responsibility  of  the  F-16  System 
Program  Director  throughout  this  phase  of  the  program.  Assisting  the  Program 
Director  in  the  Engineering  Change  Control  area  will  be  the  F-16  Multinational 
Configuration  Control  Board  (MCCB) , 

Transitional  Phase 

The  transitional  phase  is  that  period  of  time  commencing  with  PCA  and 
ending  with  overall  acceptance  of  the  engineering  and  management  of  the  system 
by  AFLC  at  the  Program  Management  Responsibility  Transfer  (PMRT)  date  set 
In  accordance  with  AFR  800-4,  Transfer  of  Program  Management  Responsibility. 

During  the  transitional  phase  only  System  Program  Office  (SPO)  approved 
changes  will  be  implemented.  The  MCCB  will  ensure  that  proper  configuration 
management  of  modified  software  is  maintained.  The  SPO  is  responsible  for 
maintaining  configuration  control  of  all  production  configurations.  Only  the 
SPO  can  authorize  expenditure  of  funds  to  make  software  changes,  including  T.O. 
compatibility  changes.  Modifications  required  will  be  processed  using  existing 
ECP  procedures.  All  changes  will  be  prioritized  by  the  F-16  SPO  with  inputs 
from  USAF/EPAF  users.  The  SPO  will  consider  the  feasibility  of  incorporating 
changes  into  the  contract  baseline  depending  upon  the  merit  of  the  change, 
the  costs  Involved,  and  the  mission  impact. 
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Details  of  the  configuration  management  organization  and  procedures  will 
be  described  in  the  Operational/Support  Configuration  Management  Procedures 
(O/S  CMP)  document  produced  during  the  Full  Scale  Development  Phase.  The  System 
Program  Director  supported  by  the  MCCB,  remains  as  the  final  authority  for  the 
approval  of  any  change  to  a  CPCI  baseline.  A  Computer  Program  Configuration 
Sub-Board  (CPCSB,  AFB  800-14,  paragraph  6-11)  will  be  established  at  Ogden 
ALC  (MMARE,  MMECA)  and  from  resident  representatives  of  the  USAF/EPAF  as  they 
deem  necessary.  Its  functions  will  be  to  supply  the  SPO  with  the  AFLC  evaluation 
of  all  change  proposals  having  an  impact  on  OFPs .  As  such,  it  will  form  the 
basis  for  the  CPCSB  which  will  exist  at  Ogden  ALC  in  the  Post-PMRT  period  and 
which  will  directly  support  the  F-16  System  Manager  and  MCCB. 

Operational  Phase 

The  Operational  phase  is  that  period  of  time  commencing  with  the  complete 
PMRT  acceptance  per  AFR  800-4,  and  continues  through  the  life  of  the  system, 

a.  The  F-16  AISF  is  used  extensively  in  the  modification  and  test 

of  the  F-16  OFPs  and  associated  documentation,  and  in  support  software  directly 
related  to  the  OFPs  (e.e.,  assembler  and  link  editor  programs),  to  data 
reduction  and  analysis  programs,  and  to  those  dynamic  and  mission  simulation 
programs  which  are  developed  to  verify  change  to  the  OFPs.  Analysis,  design/ 
coding,  validation  and  verification  (V&V)  of  software  changes  are  accomplished 
within  the  F-16  AISF.  Each  change  is  then  flight  tested  if  applicable.  Further, 
MMECA,  using  the  F-16  AISF,  has  the  responsibility  to  technically  interface 
the  OFPs  with  other  F-16  software  systems  and  to  ensure  that  hardware/software 
interface  integrity  is  maintained.  During  investigation  and  development, 
complete  records  of  events,  steps  taken,  difficulties  encountered,  and  their 
impacts  are  maintained  with  the  result  that  the  MMECA  end  product  OFP  is  fully 
documented.  When  computer  program  changes  are  contracted,  MMECA  will  monitor 
the  contractor's  progress  and  accomplish  V&V  of  the  end  product  software 
change  developed  as  part  of  the  ECP. 

b.  Each  F-16  computer  program  planned  to  be  designated  as  a  CPCI  will  be 
Identified  in  16PP153,  Table  II.  These  specifications  and  associated  documentatioi 
define  the  CPCI  baselines  which  USAF/EPAF  and  AFLC  will  maintain  during  the 
operational  phase.  Changes  to  the  computer  programs  will  require  a  corresponding 
change  to  the  Part  II  specifications  and  possibly  also  to  the  Part  I.  The  CPCSB 
will  be  the  central  point  for  processing  computer  program  changes.  All  change 
requests  to  common  CPCI  baseline  OFPs  used  by  all  USAF/EPAF  members  will  be 
agreed  upon  and  prioritized  by  joint  USAF/EPAF  action  prior  to  being  submitted 

for  incorporation  into  an  ECP.  Technical  support  from  Ogden  ALC  is  available 
to  assist  USAF/EPAF  in  this  action.  Change  requests  to  country  peculiar 
OFPs  (i.e.,  OFPs  not  utilized  by  all  members  of  the  USAF/EPAF)  will  be  handled 
in  an  identical  manner  as  far  as  configuration  management  is  concerned,  subject 
to  agreements  yet  to  be  developed. 
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c.  The  sequence  to  begin  an  Engineering  Change  Proposal  (ECP)  is  shown 
in  Figure  E-6.  Request  for  OFP  changes  to  correct  errors  or  to  improve 
capabilities  will  be  "breadboarded"  where  possible,  and  their  impact  evaluated 
as  they  are  received  by  the  SM.  Changes  not  considered  feasible  will  be 
returned  to  the  submitting  organization  with  an  appropriate  explanation.  All 
others  will  then  be  evaluated  to  determine  whether  they  involve  a  hardware  change 
to  the  aircraft  configuration  or  not.  If  the  new  requirement  has  a  hardware 
impact,  the  SM  is  responsible  for  coordination  with  the  hardware  IM  to  obtain 
the  IMs  approval  of  the  hardware  change.  When  sufficient  OFP  change  items  have 
been  accumulated  to  warrant  a  block  update  of  the  OFP  configuration,  the  total 
change  items  will  be  reviewed  jointly  by  Ogden  ALC  and  the  USAF/EPAF  users. 

In  this  review,  the  exact  change  items  to  be  included  in  the  block  update  will 
be  agreed  upon. 

d.  An  ECP  will  then  be  prepared  containing  the  engineering  data  accompanied 
by  a  description  of  the  requirement  change.  This  ECP  will  be  submitted  by  MMAR 
to  the  computer  Program  Configuration  Sub-Board  for  approval.  If  approved,  the 
SM  will  prepare  and  submit  the  appropriate  documentation  to  the  MCCB  for  approval 
or  forwarding  to  the  appropriate  level  for  funds  authorization  to  implement  the 
program  change.  If  disapproved,  information  on  status  of  the  ECP  will  be 
forwarded  to  the  originating  unit  and  other  affected  agencies.  If  during 
software  V&V  tests,  a  make-work  change  is  required.  Program  Change  Requests 
(PCRs),  as  applicable,  will  be  submitted  by  the  program  development  group  for 
approval  by  the  CPCSB  before  the  necessary  coding  changes  are  incorporated. 

The  CPCSB  will  document  each  PCR  and  determine  the  impact  of  such  changes  on  all 
affected  activities  (T.O.s,  trainers,  test  plans,  hardware,  etc.).  When  it  has 
been  determined  that  no  additional  make-work  changes  (PCRs)  are  required,  and 
upon  CPCSB  approval,  the  ECP  will  be  revised.  If  additional  funding  is  required, 
the  SM  will  amend  and  resubmit  to  the  Ogden  MCCB  the  previously  approved  modifi¬ 
cation  requirements. 

e.  When  suspected  system  OFP  problems  are  discovered,  in  the  field,  they 
will  be  documented  and  submitted  in  accordance  with  T.O.  00-35D-54,  USAF  Material 
Deficiency  Reporting  System.  They  will  be  reviewed  by  joint  USAF/EPAF  action, 
and  a  recommendation  will  be  submitted  to  the  SM  by  the  USAF/EPAF  as  to  the 
action  required  by  the  SM.  All  such  problems  requiring  OFP  changes  will  be 
separated  into  "emergency  change,"  "urgent,"  or  "collect  for  next  scheduled 
update"  categories  by  joint  decision  of  the  SM  and  USAF/EPAF.  Problems  which 
have  a  significant  impact  on  F-I6  avionics  system  capability  or  safety  will  be 
placed  in  the  emergency  or  urgent  change  category,  in  accordance  with  MIL-STD-480 
priority  definitions.  Emergency  and  urgent  changes  will  proceed  quickly  through 
the  problem  analysis,  coding  and  check-out  phase.  The  design  goal  will  be  to 
implement  the  necessary  requirements  as  quickly  as  practicable  with  a  minimum 
change  to  the  source  OFP.  Design  interface  problems  will  be  resolved  whenever 
possible  by  person-to-person  contact  and  followed  by  formal  documentation. 

f.  At  completion  of  check-out,  the  change  to  the  updated  OFP  will  undergo 
an  independent  verification,  the  goal  of  which  is  to  determine  that  the  change 
solves  the  problem  and  does  not  interfere  with  other  normal  operating  modes. 
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Figure  E-6.  Post-PMRT  Program  Change  Sequence 
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Verification  will  be  performed  in  the  AISF  and  flight  test/range  facility. 
Concurrent  with  the  verification  activity,  change  pages  to  T.O.s  will  be  written 
and  verified  in  the  AISF  and/or  during  flight  test.  At  completion  of  verifica¬ 
tion,  the  updated  OFP  and  T.O.s  are  fielded  and  trainers  and  ATE  are  updated  as 
soon  as  practical.  Documentation,  such  as  criteria,  requirements,  program 
description,  and  interface  documents,  is  made  compatible  with  the  new  program. 

g.  Support  software  such  as  compilers,  assemblers,  simulators,  loaders, 
link  editors,  and  V&V  programs  will  be  updated  by  ACDCS  and  MMECA  direction  to 
reflect  changes  made  to  the  operational  software.  During  the  operational  soft¬ 
ware  change  cycle,  required  changes  to  support  software  and  hardware  will  be 
accomplished  to  accommodate  the  operational  software  change(s).  Both  support 
hardware  and  software  baseline  documentation  will  be  maintained  to  show  details 
of  all  changes  required  for  a  particular  operational  software  change.  Then, 
upon  approval  of  new/revised  operational  software,  these  data  will  be  updated  to 
indicate  permanent  change  approval.  Changes  to  support  software/hardware  to 
enhance  their  capabilities  will  be  thoroughly  documented  and  controlled  by 
OOALC/MME.  A  configuration  management  program  will  be  developed  and  maintained 
within  MME  to  show  baseline  software  configuration  and  changes  thereto  accom¬ 
plished  during  the  OFP  software  update.  This  program  will  assure  adequate 
control  over  the  engineering  development  processes  prior  to  release  to  the  field 
by  the  F-16  SM. 
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CONFIGURATION  MANAGEMENT  CONCEPTS 


Classes  of  Configuration  Changes: 


Class  I  Changes: 


For  the  purpose  of  the  O/SCMP,  MIL-STD-483  (USAF) ,  Appendix  XIV, 

Paragraph  140.6.1’,  shall  be  the  recognized  definition  of  Class  I  changes. 

Class  II  Changes: 

For  the  purpose  of  the  O/SCMP,  MIL-STD-483  (USAF),  Appendix  XIV, 

Paragraph  140.6.2,  shall  be  the  recognized  definition  Class  II  changfes. 

After  PCA  of  computer  programs,  and  prior  to  PMRT,  there  will  be  no 
Class  II  changes  allowed. 

Priorities  of  Configuration  Changes:  For  the  purpose  of  the  O/SCMP,  MIL-STD-480, 
Paragraph  4.5,  provides  the  definition  of  Class  I  Emergency,  Urgent  and  Routine 
engineering  change  priorities. 

Computer  Program  Configuration  Items  (CPCI) : 

Definition  of  a  Computer  Program  Configuration  Item:  A  computer  program  end 
product  whose  development  and  subsequent  modification  is  subject  to 
configuration  management. 

Baseline  Documentation  of  CPCIs:  The  "Contract  Data  Requirements  List"  (CDRL) , 

DD  Form  1423,  is  the  sole  contractual  document  listing  all  data  to  be  delivered 
under  the  contract.  For  computer  programs,  this  usually  includes  Parts  I  and  II 
specifications,  users'  and  programmers '  manuals,  configuration  management 
baseline  documentation,  test  plans  and  results,  end  item  delivery  format  and 
ECP  submittals.  Annexes  to  this  O/SCMP  shall  include  specific  CDRL  requirements. 

Assignment  of  Computer  Program  Identification  Numbers: 

Computer  Program  Identification  Number  (CPIN) :  Computer  programs, 
support  programs  and  related  documentation  will  be  separately  identified 
through  a  centrally  controlled  standard  Air  Force  system  maintained  and 
operated  by  OC-ALC/MMEDU  and  supported  by  OC-ALC/ACDT.  To  maintain  the 
CPIN  system,  a  separate  subsystem  under  G022,  Logistics  Management  of 
Technical  Order  System,  is  under  development.  The  Data  System  Designator 
for  this  subsystem  is  Q016.  The  centrally  controlled  numbering  system 
also  permits  OC-ALC  to  issue  a  compendium  for  all  items  identified  as 
CPINs.  A  CPIN  number  shall  be  assigned  to  each  CPCI  in  the  F-16 
Weapon  System. 

CPCI  NUMBER: 


CPCI  Number:  In  accordance  with  AFR  65-3,  MIL-STD-483  and 
AFR  800-14,  each  computer  program  or  aggregated  programs  subject 
to  configuration  management  shall  be  designated  as  a  Computer 
Program  Configuration  Item  (CPCI). 
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Supplier  P/N:  All  computer  programs  (CPCIs)  provided  in  the  F-16 
program  have  supplier  part  numbers  assigned  to  them.  These  part 
numbers  shall  be  used  as  the  item  identifier  in  configuration 
management  status  accounting  and  control  processes.  It  is  also 
known  as  the  "alternate  number"  in  the  CPIN  system. 

Configuration  Management  Phases: 

Implementation  Phase:  The  implementation  phase  is  that  period  of  time  beginning 
with  the  conception  of  the  system  and  ending  at  the  end  item  physical  configura¬ 
tion  audit  (PCA) .  Software  configuration  management,  documentation,  reviews  and 
audits  for  both  operational  and  support  software  shall  be  developed  and  conducted 
in  accordance  with  the  guidance  provided  by  MIL-STDs-480 ,  483,  490,  and  1521. 

The  product  baseline  will  be  established  after  all  changes  required  for  accept¬ 
able  performance  have  oeen  implemented,  verified,  and  documented.  Changes  to 
CPCIs  will  be  proposed,  formatted  and  processed  in  accordance  with  M1L-STD-480 
and  483.  Engineering  change  control  authority  is  the  responsibility  of  the  F-16 
System  Program  Director  (ASD/YP)  throughout  this  phase  of  the  program.  Assist¬ 
ing  the  program  director  in  the  engineering  change  control  area  will  be  the 
F-16  Multinational  Configuration  Control  Board  (MCCB) . 

Transitional  Phase  (Pre-PMRT) :  The  transitional  phase  is  that  period  of  time 
commencing  with  PCA  and  ending  with  overall  acceptance  of  the  engineering  and 
management  of  the  system  by  AFLC  at  the  Program  Management  Responsibility 
Transfer  (PMRT)  data  set  in  accordance  with  AFR  800-4,  Transfer  of  Program 
Management  Responsibility. 

The  System  Program  Director,  supported  by  the  MCCB,  remains  as  the  final 
authority  for  the  approval  of  any  change  to  a  CPCI  baseline.  Prior  to 
PMRT,  the  Computer  Program  Configuration  Sub-Board  (CPCSB,  AFR  800-14, 

Paragraph  6-11)  will  be  established  at  Ogden  ALC  (MMA)  from  resident 
representatives  of  the  USAF  and  EPAF.  As  such,  it  will  form  the  basis 
for  the  CPCSB  which  will  exist  at  Ogden  ALC  in  the  Post-PMRT  period.  The 
TAC  representative  will  be  from  HQ  TAC.  The  CPCSB  established  prior  to 
PMRT  shall  act  only  on  those  responsibilities  delegated  to  it  by  the  MCCB. 

During  the  transitional  phase,  only  System  Program  Office  (SPO)  approved 
changes  will  be  implemented.  The  MCCB  will  ensure  that  proper  configura¬ 
tion  management  of  modified  software  is  maintained.  The  SPO  is  respon¬ 
sible  for  maintaining  configuration  control  of  all  production  configura¬ 
tions.  Only  the  SPO  can  authorize  expenditure  of  funds  to  make  software 
changes,  including  TO  compatibility  changes.  Modifications  required  will 
be  processed  using  existing  ECP  procedures.  All  changes  will  be 
prioritized  by  the  F-16  SPO  with  inputs  from  USAF/EPAF  supporting  and 
using  commands.  The  SPO  will  consider  the  feasibility  of  incorporating 
changes  into  the  contract  baseline  depending  upon  the  merit  of  the  change, 
the  costs  involved,  and  the  mission  impact. 

Operational  Phase  (Post-PMRT):  The  operational  phase  is  that  period  of  time 
commencing  with  the  complete  PMRT  acceptance  per  AFR  800-4,  and  continued 
through  the  life  of  the  weapons  system. 

A  Computer  Program  Configuration  Sub-Board  (CPCSB,  AFR  800-14, 

Paragraph  6-11),  consisting  of  resident  representatives  of  the 
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USAF  and  EPAF,  will  be  established  at  Ogden  ALC  to  function  in  the 
Post-PMRT  period.  The  CPCSB  will  operate  within  the  guidelines 
established  in  the  Post-PMRT  Multinational  Configuration  Management 
Plan  (Steering  Committee  Decision  No.  22)  and  perform  support 
responsibilities  assigned  to  it  by  the  MCCB. 

After  a  system  is  in  operational  use,  changes  to  computer  programs 
may  be  necessary  to  remove  latent  errors,  improve  coding  or  operation, 
adapt  to  changes  in  system  requirements,  or  incorporate  knowledge 
gained  from  operational  use.  Based  upon  complexity  and  other  factors 
such  as  system  interfaces,  constraints,  and  priorities,  control  may 
vary  from  on-site  management  to  complex  checks  and  balances  with 
mandatory  security  keys  and  access  codes.  The  authority  to  change 
the  computer  programs  must  be  carefully  and  specifically  delineated, 
particularly  when  security,  safety,  or  special  nuclear  restrictions  are 
involved.  Engineering  change  control  authority  is  the  responsibility 
of  the  system  manager.  The  CPCSB  performs  support  responsibilities 
assigned  to  it  by  the  MCCB. 
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STATUS  ACCOUNTING: 

The  equipment  maintenance  status  accounting  used  by  AFLC  after  F-16  items  have  been 
delivered  to  the  using  organizations  is  based  on  AFLCR  66-16. 

All  computer  programs  designated  as  CPCls  shall  be  accounted  for  on  the  Advance 
Configuration  Management  System  (ACMS) ,  DO-57G. 

The  Advanced  Configuration  Management  System  record  contains  the  following  elements: 

FSC/Part  Number  Identification  -  This  may  be  either  the  CPCI  number, 
or  manufacturer's  (supplier)  part  number,  or  an  abbreviated  CPIN 
to  15  digits. 

TCTO  Data 

Correction  Data 

Location  Data 

Serial  number  identification  -  The  computer  program  will  share  the 
same  serial  number  assigned  to  the  end  computer  hardware  item. 

Removal  and  Installation 

Component  Relationship 
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STRUCTURED  DESIGN?  -  DESCRIBE  Generally,  No. 

OFP  not  structured.  The  OO-ALC  INS  OFP  Flowchart  is  structured  (IFTRAN) 

Future  programs  will  embody  structured  design. 

The  Radar  OFP  comprises  29  components,  each  performing  particular  tasks. 


STRUCTURED  PROGRAMMING?  -  DESCRIBE 

Not  currently.  Where  applicable,  new  mods  will  be  structured  if  OFP  module 
can  accommodate. 


CODING  GUIDELINES: 

Identical  to  "Programming  and  Software  Documentation  Standards  for  the  F-4  Weapon 
System  Test  Complex  at  Ogden  ALC,"  30  June  1976.  It  requires  structured  design, 
flowcharting  and  coding  using  IFTRAN  language  and  pre-processors . 


CHANGE  ENTRY  METHODS: 

Use  TSO  text-editor  package  to  modify  source  statements. 
Backup  storage  of  two  previous  versions. 


SCHEDULE: 

Formal  block  change  schedule:  Block  II  Schedule  (18  months) 

Block  III  Schedule  (9  mouths) 
Thereafter  (12  months) 


REPORTING: 

See  pages  E-54  and  E-55 


COMMENTS:  Contracts  do  not  specify  requirements  for  structured  programming  in  OFP. 
Contractor  supplied  programming  standards  are  used.  FCC  is  80  percent  JOVIAL  HOL; 
Other  OFP's  are  assembly  language.  Support/Simulation  software  is  Fortran  and  IBM  360 
Basic  Assembly  Language  (BAL) 
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DOCUMENTATION:  See  pages  E-45  through  E-48. 

REQUIREMENTS:  MMECA  writes  a  Development  Specification  for  any  new 

software  package. 

Changes  are  requested  using  a  standard  form. 

B-5 

DESIGN:  Contractor  format  patterned  after  MIL-STD-483/490 

ACDCS  writes  a  Product  Specification  describing  the  design 
of  the  software  needed  to  implement  the  requirements  specifications. 


USER:  C-5 

A  User's  Manual  is  written  for  each  new  software  package. 

A  Version  Description  Document  is  written  for  each  modification 
to  an  existing  software  (configured)  item. 

Manuals :  Pilot's  Manual 

Standard  Support  Software  Manual 
Computer  Programming  Manual  Guide 


( 


PROGRAM  PROBLEM  REPORTING  SYSTEM:  See  pages  E-49  and  E-50  • 


COMMENTS: 
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DOCUMENTATION 

General 

It  is  imperative  that  adequate  documentation  be  provided  in  order  to  properly 
operate,  maintain,  modify,  and  otherwise  support  the  OFP  after  acceptance.  Such 
documentation  should  include  not  only  that  applicable  to  the  OFPs  themselves,  but 
also  that  applicable  to  the  design,  operation  and  maintenance  of  the  OFP  support 
equipment  in  the  F-16  AISF,  that  applicable  to  the  OFP  utility  support  software 
(Assemblers  etc.),  and  that  necessary  for  the  USAF/EPAF  users  to  accomplish  their 
OFP  support  functions.  Within  the  limits  of  F-16  disclosure  guidance  authorized 
at  the  time  of  EPAF  requests,  documentation  will  be  made  available  to  EPAF 
representatives  in  their  home  country.  Such  documentation  may  include  data  related 
to  programming  languages,  specifications,  program  descriptions,  etc.  in  the 
appropriate  media.  Such  documentation  is  being  developed  during  the  Full  Scale 
Development  Phase  by  the  SPO  (see  Tables  E-l  and  E-2) ,  and  will  be  updated  by  the 
SPO  as  necessary  until  PMRT  occurs,  at  which  time  the  SM  will  continue  that  update 
responsibility.  In  order  to  allow  OOALC/USAF/EPAF  personnel  to  become  cognizant 
of  the  OFPs  and  AISF  early  in  the  program,  and  to  facilitate  a  quick  and  orderly 
transfer  of  engineering  responsibility,  users  with  data  requirements  will  order 
such  data  through  the  F-16  SPO.  Till  documentation  will  use  applicable  military 
standard  formats  or  will  conform  to  the  contractor's  best  commercial  practices  as 
appropriate.  Other  contractor-generated  data  not  specified  in  the  Contract  Data 
Requirements  List  may  be  acquired  on  one-time  basis  via  the  Data  Accession  List 
during  FSD. 

AISF  Support 

As  each  set  of  equipment  for  each  OFP  is  acquired,  the  F-16  SPO  and  Ogden  ALC 
will  establish  the  necessary  data  requirements.  Currently,  the  Avionics 
Equipment  Bay  (AEB)  is  being  procured  as  an  item  of  support  equipment  and 
the  Dynamic  System  Simulator  (DSS)  is  being  procured  under  an  AFALD  contract 
These  separate,  distinct  actions  preclude  developing  a  data  matrix  similar 
to  Table  E-2. 

However,  typical  data  deliveries  will  baseline  the  equipment  design,  operation, 
maintenance  and  provide  provisions  to  maintain  configuration  reporting. 
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TABLE  E-l.  DATA  ITEM  DESCRIPTION  TITLES 


DI-E-3119A 


DI-E-3120A 


Computer  Program  Development 
Specification 

Computer  Program  Product 
Specification 


DI-E-3121 


Version  Description  Document 
(Computer  Program) 


DI-E-3122 


Configuration  Index 
(Computer  Program) 


DI-E-3123 


DI-M- 3410/M 


Change  Status  Report 
(Computet  Program) 

Users  Manual  (Computer  Program) / 
Modified 


DI-M- 3411/M 


Computer  Programming  Manual/ 
Modified 


DI-T-3703 


Category  I  Test  Plan/ 
Procedures  (Computer  Programs) 


DI-T-3717 


DI-H-5072/M 


Category  Test  Report 
(Computer  Programs) 

Contract  End  Item  Format 
Requirements  (Software) /Modified 
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DEFICIENCY  REPORT / CHANGE  PROCEDURES:  The  USAF  Material  Deficiency  Reporting  and 
Investigating  System,  TO  00-35D-54,  establishes  the  system  that  will  feed  back 
deficiency  data  on  computer  programs,  so  that  corrective  action  may  be  taken. 

Following  is  a  brief  synopsis  of  deficiency  report  categories: 

a.  Category  I  Material  Deficiency  Report  (MDR) :  A  report  of  an  emergency  condition 
on  computer  programs  which  presents,  or  has  the  clear  potential  to  present  an 
unacceptable  safety,  operational,  or  maintenance  hazard. 

b.  Category  II  MDR:  Deficiencies  in  computer  programs  which  are  related  to  errors 
generated  in  design  and  production  or  changes  that  could  upgrade  its  operation. 

This  does  not  include  major  modification  program  efforts  to  produce  a  new 
capability. 

Pre-PMRT  Change  Process:  Prior  to  PMRT,  only  System  Program  Office  (SPO)  approval 
changes  will  be  implemented.  During  this  period,  the  F-16  SPO  is  responsible  for 
the  F-16  Deficiency  Reporting  Program  and  YPCB  is  the  designated  single  point  of 
contact  for  all  deficiency  reports.  YPOI  800-9,  processing  of  F-16  Deficiency 
Reports  (DRs) ,  establishes  the  responsibilities  and  procedures  for  the  processing, 
evaluation  and  disposition  of  F-16  DRs  for  all  personnel  assigned  or  attached  to 
the  Deputy  for  F-16.  The  System  Program  Director,  supported  by  the  MCCB,  remains 
as  the  final  authority  for  approval  for  any  change.  His  approval  is  required  as 
DRs /changes  are  submitted  in  requests  for  Engineering  Change  Proposals. 

YP  01  800-3,  Advance  Change  Study  Notices  (ACSNs) ,  Contract  Change  Proposals  (ECPs) 
Processing,  describes  the  F-16  SPO  procedures  allow  supporting/implementing 
command/country  participation  in  the  solicitation/evaluation  of  DRs  and  other 
changes.  Additionally,  they  are  represented  at  MDRB  meetings. 

Post -PMRT  Change  Process:  Figure  E-6  (page  E-41)  graphically  illustrates  the 
software  change  process  following  PMRT.  All  F-16  airborne  software  (OFPs)  are 
assigned  to  the  System  Manager  (SM)  at  Ogden  ALC.  Also  all  F-16  peculiar  AICS  LRU 
and  SRU  items  are  MMAC  coded  to  the  Ogden  ALC  System  Manager.  Therefore,  this 
process  shall  apply  to  avionics,  AIS,  Depot  and  microprocessor  subsystem/support 
equipment  categories. 

Change  Request  Submittals:  Most  frequently,  changes  will  originate  through 
deficiency  reports  submitted  in  accordance  with  TO  00-35D-54.  All  MDRs  will 
be  prepared  on  the  DD  Form  173,  Joint  Messages,  and  submitted  electrical 
transmission.  The  format  used  shall  be  Standard  Form  368,  Quality  Deficiency 
Report,  blocks  3  through  22  (AFR  74-6).  Changes  may  also  be  initiated 
through  unsolicited  ECPs,  letters,  etc.  All  change  activity  shall  be  controlled 
through  the  Material  Improvement  Program  (MIP)  and  tracked  with  G026  reporting 
system. 

Screening  Function:  The  System  Manager  shall  perform  a  preliminary  review  of 
all  DRs  and  other  change  recommendations.  All  members  of  the  CPCSB  shall 
receive  copies  of  these  documents  at  least  two  weeks  prior  to  the  CPCSB  meeting. 

They  will  be  distributed  on  a  regular  basis  for  maximum  awareness.  The  SM 
may  assemble  a  technical  review  team  of  CPCSB  members  and  applicable 
IM/MME/MACT  engineers  and  technicians  required  to  isolate  the  problem  and 
separate  hardware  versus  software  discrepancies.  This  function  may  include 
AISF  testing  as  well  as  contractor  tasking.  The  technical  review  team  shall 
assist  the  SM  in  the  preparation  of  required  forms  for  CPCSB  and  MCCB  action 
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as  described  in  the  following  paragraph.  Related  LRU/SRU  test  program  impacts 
will  also  be  assessed.  Finally ,  the  CPCSB  shall  provide  approval  or 
disapproval  of  continuing  the  project.  The  Trainer  Device  Manager  (MMT) 
representative  of  the  CPCSB  shall  initiate  impacted  changes  for  the  Operational 
Flight  Trainer  (OFT)  and  Simulated  Aircraft  Maintenance  Trainer  (SAMT)  design. 
Impacted  System  and  Item  Managers  external  to  OO-ALC  shall  be  notified  early 
of  impending  changes  affecting  their  interfaced  equipment.  Their  participation 
on  the  CPCSB  for  the  related  project  may  be  considered  desirable. 

Project  Formalization: 

a.  Software  change  requirements  shall  be  documented  on  AFLC  Form  75 
by  the  System  Manager. 

b.  Software  change  requirements  resulting  from  or  causing  hardware 
modifications  will  require  AFLC  Form  75  to  be  appended  to 

AFLC  Form  48  (Class  IV  modification).  For  Class  V  modifications, 

AFLC  Form  2600  series  (i.e.,  2612,  2613,  etc.)  are  applicable. 

Total  software  cost  will  be  identified  in  block  12F  of  the 
AFLC  Form  48.  The  budget  project  column  on  this  form  will  be 
annotated  EEIC  583  for  software  requirements. 

c.  Once  a  change  requirement  has  been  identified,  verified  and 
defined  it  may  next  be  held  in  a  "loop"  awaiting  an  appropriate 
implementation  time.  This  delay  may  be  caused  by  various 
factors  (i.e.,  grouping  of  block  update  changes,  memory  and 
timing  approval  of  the  Configuration  Steering  Group  (CSG), 

low  impact  priority,  etc.). 


PREDICTIVE  SOFTWARE  COST  MODEL 

PERSONNEL  DESCRIPTION _ DATE:  31  October  1979 

DESCRIPTION  OF  SKILL  LEVEL  AMD  TYPE  (AF/CS/CONT)  OF  PERSONNEL  MAINTAINING  THIS  PACKAGE 

I.  OFP  Engineers  are  EE/math  trained,  generally  skilled  as  systems  engineers. 

II.  DUTIES  AND  RESPONSIBILITIES 

1.  The  incumbents  perform  a  variety  of  computer  resource  engineering  and 
related  assignments  in  support  of  research,  advanced,  and/or  production  Air  Force 
Weapon  systems.  The  work  may  be  in  one  of  the  major  functional  areas  of  computer 
resource  functional  requirements,  operational  oi  system  test  computer  resources. 

The  work  is  generally  broken  down  into  tasks,  and  the  incumbents  are  responsible 
for  the  planning  and  execution  of  such  tasks  under  the  technical  direction  of  an 
avionics  systems  functional  expert  for  the  particular  functions  involved. 

2.  The  incumbents  execute  tasks  of  high  complexity,  and  must  have  a  detailed 
knowledge  of  the  impact  of  the  computer  resources  on  the  performance  of  the  weapons 
system.  This  requires  a  detailed  knowledge  of  the  applicable  computer  program 

and  computer  hardware  performance  characteristics. 

3.  The  incumbents  assist  in  the  solution  of  difficult  avionics  engineering 
problems  and  implement  the  solution  to  such  problems  via  the  appropriate  avionics 
computer  program.  The  incumbents  accomplish  such  action  in  conformance  with 

the  principles  and  practices  identified  in  AFR  800-14  Vols  I  and  II.  These 
problems  are  normally  ones  that  have  not  been  previously  solved,  and  thus  have  no 
precedent.  In  order  to  solve  such  problems,  the  incumbents  bridge  the  gap  between 
the  problem  requirements  and  the  methods  and  techniques  available  in  the 
existing  technology. 

4.  The  duties  of  the  incumbents  involve  major  responsibility  for  one  or  more 
of  the  following  depending  on  the  system  requirements: 

a.  Analysis  of  digital  avionic  system  functional  and  performance  require¬ 
ments  including  the  system's  operational  environment,  crew  capabilities  and 
training,  avionic  equipment  capabilities  and  performance  characteristics,  man/ 
machine  interface,  special  compatibility  requirements  in  areas  such  as  programming 
language,  documentation  standards,  etc. 

b.  Formulation  of  avionic  system  development  approaches  and  procurement 
strategies . 

c.  Definition  and  development  of  the  operating  procedures,  tools  and 
facilitities  necessary  to  support  the  development  approach. 

d.  Preparation  of  materials  and  the  definition  and  execution  of  procedures 
and  tasks  necessary  to  effect  procurement  strategies. 

e.  Definition,  design,  development  and  documentation  of  the  operational 
and  support  computer  resources  necessary  to  meet  the  system's  functional  and  per¬ 
formance  requirements  together  with  providing  assistance  as  required  in  the 
integration,  test  and  evaluation  of  such  computer  resources. 

f.  Maintain  a  knowledge  of  computer  architectures,  interface  requirements 
and  programming  languages  for  application  in  solving  data  processing  requirements 
of  both  existing  and  proposed  systems. 
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g.  Assist  in  conducting  laboratory  and/or  system  demonstrations  as 

required. 

h.  Monitor  contractor  oriented  tasks  by  chairing  design  reviews  and 
reviewing  and  approving  delivered  documentation,  etc. 

i.  Monitors  all  Engineering  Change  Proposals  (ECPs)  and  TCTOs  to  assure 
that  configuration  changes  do  not  affect  computer  program  interfaces. 

j.  Provides  engineering  advisory  and  consultation  services  for  Air 
Force  activities  as  required. 

k.  Performs  other  duties  as  directed. 


III.  OTHER  SIGNIFICANT  FACTS 

The  incumbents  must  have  a  thorough  knowledge  of  the  fundamentals  of 
engineering,  and  mathematics  such  as  would  be  required  of  a  Bachelor  of  Science 
degree  in  Engineering,  Physics  or  Mathematics.  In  addition,  the  position  requires 
a  minimum  of  one  year's  experience  in  any  one  or  all  of  the  areas  of  systems 
analysis,  digital  computer  systems,  programming  languages  and  system  development 
techniques.  The  incumbents  must  possess  the  capability  to  quickly  correlate  the 
technical,  administrative  and  economic  aspects  of  the  work  to  assure  a  cost- 
effective  system  development. 


IV.  TYPICAL  EXPERIENCE 

GS-12  Electronics  Engineer  with  experience  in  Embedded  Computer  Systems. 

Typically  would  have  8-15  years  experience  in  aircraft  systems  and 
software  support. 

Normally  have  had  40-80  hours  specialized  class  training  on 
microprocessor/assembly  language,  Fortran  IV.  Education  level 
includes  BS,  MS,  Ph.D  candidate. 


V.  ORGANIC  VERSUS  CONTRACTOR 

It  is  expected  that  not  all  OFP  support  will  be  organic  following  PMRT. 

PMRT  is  1985  with  OFPs  now  under  Reliability  Improvement  Warranty  (RIW)  until  1983. 
An  AF  study  using  the  F-16  will  be  the  basis  for  determination  of  subsystem 
support  by  the  ALC. 
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BUILDINGS: 

MMECA/ACDCS  -  5000  Square  Feet 
(50%  use-shared  with  F-4) 


DATE:  31  October  1979 


MMETA  - 


AISF  including  AEB  (tower)  13,000  Square  Feet 
DSS  Room  3,000  Square  Feet  Raised  Floor 
AIS  Room  3,600  Square  Feet 
AEB  Room  1,250  Square  Feet 
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COMPUTER  FACILITIES  (Type,  Quantity,  Application,  Co*t  &  Usage) 

OFP  activities  are  split  between  MMECA  evaluation  and  simulation  via  OS  360-TSO, 

MMETA  test  using  the  avionics  Integrated  Support  Facility  (AISF) ,  and  actual 
flight  test.  CfFP  testing  is  indicated  in  Figure  E-7.  The  ACDCS  OS  360  system  is 
shown  in  Figure  E-8.  The  Dynamic  System  Simulator  (DSS)  is  shown  in  Figure  E-9. 

The  purpose  of  the  support  test  beds  for  maintenance  of  F-16  OFPs  is  to  provide 
the  necessary  tools  to  identify  OFP  errors,  optimize  OFP  operation  and  handle  new 
OFP  operational  concepts  during  the  life  cycle  of  the  F-16  aircraft.  The  proposed 
test  beds  are  functionally  organized  into  four  parts.  These  include  a  General 
Purpose  Computer  Complex  (GPCC)  for  creation  of  OFP  tapes,  Dynamic  Test  Stations 
(DTS)  to  check  out  the  individual  OFPs  in  real  time  with  a  simulated  real  world 
environment,  and  Avionics  Equipment  Bay  (AEB)  to  test  the  interfaces  between 
the  various  avionics  systems,  and  a  Flight  Test  Aircraft  Range  Facility  to  test 
the  system  in  an  operational  environment.  The  proposed  capabilities  to  be  provided 
by  these  equipments  and  facilities  and  the  OFP  Support  System  Flow  are  discussed 
below  and  shown  in  Figure  E-10.  The  total  OFP  support  process  will  involve  use  of 
all  of  the  described  equipments  and  facilities. 

The  proposed  support  system  will,  in  all  likelihood,  be  of  the  same  order  of 
magnitude  of  complexity  as  the  systems  whose  problems  it  is  intended  to  solve. 

One  of  the  basic  system  design  requirements  is,  therefore,  that  the  facilities 
be  designed  such  that  the  test  engineer  has  a  high  degree  of  confidence  in  the 
support  facilities  functions.  Valuable  resources  will  be  wasted  if  the  test 
engineers  have  to  decide  whether  the  causes  of  anomalous  behavior  lie  in  the 
support  facility  or  in  the  avionics  under  test.  The  support  facilities  must 
therefore  provide  diagnostic  capabilities  to  determine  the  integrity  of  the  support 
facilities  and  isolate  any  problems  associated  with  the  support  facilities.  In 
addition,  a  self-test  capability  should  be  included  that  provides  a  go/no-go 
overall  closed- loop  test  to  be  performed  before  use  of  the  DTS  or  AEB.  This 
insures  that  the  test  facilities  are  functioning  normally  and  promotes  test  engineer 
confidence  in  use  of  the  system.  In  addition,  each  facility  will  undergo  certifi¬ 
cation  testing  as  a  final  portion  of  each  development  segment.  The  testing  will 
consist  of  comparison  of  results  from  all  facilities  against  flight  test  results 
with  all  discrepancies  corrected  or  explained. 

General  Purpose  Computer  Complex  (GPCC) 

As  shown  in  Figure  E-7,  the  GPCC  is  the  first  step  in  the  OFP  support  system  flow. 

The  purpose  of  this  facility  is  to  provide  the  necessary  support  for  OFP  development 
required  before  testing  on  the  Dynamic  Test  Stations.  These  support  tasks  would 
include  algorithm  evaluation  of  proposed  OFP  changes,  logging  all  OFP  changes, 
assembly  and  creation  of  OFPs  for  testing  and  operational  use,  preliminary  check¬ 
out  of  new  OFP  code,  reduction  of  flight  test  simulation  data  and  support  of 
configuration  management  tasks  (e.g.,  file  management,  automatic  flow  charting). 

The  GPCC  will  support  these  activities  with  a  general  purpose  IBM  360-65  computer 
available  at  Ogden  ALC  (see  Figure  E-8).  This  general  purpose  computer  can  provide 
the  necessary  resources  to  perform  the  functions  described  above.  These  include 
a  Higher  Order  Language  (e.g.,  FORTRAN,  JOVIAL  J3B)  for  algorithm  evaluation  and 
data  reduction  programs,  assemblers/compilers  for  various  flight  computers, 
functional  simulations  of  the  various  flight  computers  for  initial  code  check-out, 
document  generation  and  maintenance  using  editing  and  test  processing  features,  etc. 

The  GPCC  will  not  be  dedicated  to  the  F-16  support  facility.  Use  of  the  general 
purpose  computer  will,  therefore,  be  in  either  a  batch,  remote-job-entry,  or 
interactive  timesharing  mode. 
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F-16  Avionics  Integration  Support  Facility  (AISF)  Equipment 

The  F-16  AISF  will  contain  the  support  equipment  necessary  to  maintain  selected 

F-16  OFPs  at  Ogden  ALC  throughout  the  life  of  the  F-16.  The  support  equipment  will 

be  of  two  types,  Dynamic  Test  Stations,  and  Avionics  Equipment  Bay. 

a.  The  Dynamic  System  Simulator  (DSS)  is  a  FCC  OFP  test  stand  which  can  be 
operated  in  various  modes  for  FCC  OFP  components  interface  testing.  A  decision 
to  develop  an  in-house  capability  was  made  based  upon  a  comparison  of  the 

cost  required  to  establish  such  a  capability  in  the  AISF  versus  the  cost  for 
contractor  support  via  his  in-plant  support  equipment  for  the  workload  esti¬ 
mated  for  that  OFP. 

Tiie  Simulator  Host  Computer  (SHC)  will  provide  modes  simulating  the  aircraft 
response  and  flight  sensors  as  well  as  a  real  world  model  for  dynamic 
simulation  of  the  F-16  performance  in  an  operational  environment.  The  OFP 
output  from  the  DSS  will  be  processed  by  the  SHC  with  its  models,  the  response 
conditioned,  and  inputted  back  to  the  OFP.  This  complex  will  be  used  to  make 
and  check  OFP  updates.  The  internal  procedures  for  the  change  process  of  a 
new  OFP  will  reflect  those  established  by  Ogden  ALC/MME. 

b.  The  Avionic  Equipment  Bay  is  a  hot  mock-up  of  the  forward  fuselage  containing 
those  F-16  avionics  having  digital  interface  with  the  F-16  OFPs.  It  is  used 
for  system  integration  of  various  combinations  of  hardware  and  software. 

c.  The  AISF  will  contain  those  resources  necessary  to  modify,  test,  reproduce 
and  distribute  AIS  software.  The  software  preparation  stations  will  be  used 
to  update,  modify  and  maintain  control,  support  and  test  software  for  the 
four  types  of  F-16  AIS  test  stations.  Additionally,  it  will  be  used  for 
preparation  of  new  test  programs  required  to  test  additional  LRUs  on  the  AIS. 
The  AIS  test  stations  will  be  used  for  engineering  analysis  of  hardware/soft¬ 
ware  problems,  evaluation  of  proposed  design  changes,  integration  of  AIS 
elements,  and  V&V  of  all  changed  programs.  They  will  be  utilized  to  assure 
design  and  performance  compatibility  between  the  Avionics  Self  Test /Built-in 
Test  and  AIS  test  programs.  The  AIS  will  also  be  used  in  support  of  hardware/ 
software  modifications  to  the  test  stations. 

The  AISF  will  contain  an  Interface  Test  Adapter  modifying  area  for  prototyping/ 
modifying  ITAs.  Additionally,  an  AIS  documentation  library  within  the  AISF 
will  have  the  necessary  equipment  to  reproduce  and  distribute  changed  programs. 
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IBM  360/65  Quantity  =  1 


The  IBM  360  is  used  for  the  following: 


1.  Generate  OFP  machine  code. 

2.  Testing  with  interpretive  simulation  programs. 

3.  Checkout  of  HOL  written  algorithms  (FORTRAN). 

4.  Analyze  flight  test  data. 

5.  MIS  Programs. 


Languages : 

7  computer 
1  printer 

Requl re 


FORTRAN  (90  percent)  COBOL  (10  percent) 

terminals  I 

|  computer  support 

d  pui  tours  for  POR  OFP  Test  of  F-4,  F-16. 


OATS: 


MMi TA : 


F-16  A ISF  -  (See  attached  list  of  equipment) 

ATS  -  Automated  Test  Equipment  to  support  field 
automatic  test  equipment 

*50  percent  software  support,  50  percent  hardware  support 

o  4  test  stands 
o  Adapters 

o  Peculiar  Test  Equipment 

AEB  (Tower)  -  hot  avionics  mock-up  to  bench  test  OFP 
compatibility  and  hardware  mods. 

*40  percent  software  support,  60  percent  hardware  support 

o  Test  Bench 
o  Hot  Mock-up 
o  Peculiar  T.E. 

DSS/SMOP  DTC  -  simulator  -  *100  percent  software  support 
and  RES  (bid  not  in  yet) 


31  October 


7.5M* 


$  4.3M* 


10. 5M* 


37A 
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F-16  AISF 


DEC  5'- stem  10 


DMA- 10 


Line  Printer 


DEC  VT-100 


DEC  11-55 


DEC  11-34 


VT-100 


Picture  System  2 


DATE:  31  October  1979 


Host  Simulation  Computer 
DEC  Sys.  10  DMA  Window 


Tape  Drives 


Terminals 

Connector  Between  DEC  Sys  10 
and  DSS 


Terminal 

Evans  and  Southerland  Graphic 
Display  Sys. 
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Software 

Host 

Language 

Size* 

Vendor  Supplied 
-  application 
unknown 

IBM  360/65 

Fortran 

33867  lines 

code 

And 

comment 

FCC  Data  Reduction 

IBM  360/65 

Fortran 

8346  lines 

code 

and 

comment 

FCR  Data  Reduction 

IBM  360/65 

Fortran 

6230  lines 

code 

and 

comment 

SM  Data  Reduction 

IBM  360/65 

Fortran 

6570  lines 

code 

and 

comment 

General  Support 

IBM  360/65 

Fortran 

576  lines 

code 

and 

comment 

FCC  Postflight 

IBM  360/65 

Fortran 

4378  lines 

code 

and 

comment 

SM  Postflight 

IBM  360/65 

Fortran 

3664  lines 

code 

and 

comment 

FCR  Postflight 

IBM  360/65 

Fortran 

3154  lines 

code 

and 

comment 

SMS  Cross  Assembler 

IBM  360/65 

Fortran 

277K  words 

INS  Cross  Assembler 

IBM  360/65 

Fortran  & 
BAL 

220K  words 

INS  Cross  Link  Edit 

IBM  360/65 

Fortran  & 
BAL 

120K  words 

INS  Simulator 

IBM  360/65 

Fortran  & 
BAL 

150K  words 

INS  RPG 

IBM  360/65 

Fortran  & 
BAL 

62K  words 

INS  Post  Processing 

IBM  360/65 

Fortran  & 
BAL 

94K  words 

DSS  Control/Monitor 

PDP-11/34 

AL 

24K  words 

AEB 

Delco  Alpha 

AL 

32K  words 

L&S  Picture  System 

PDP-11/ 55 

Fortran 
(5%  AL) 

96K  words 

AISF  System  SIM 

DEC- 10 

Fortran 

768K  words 

Bus  Monitor 

PDP-11/55 

AI, 

28K  words 

*NOTE:  No  Line/Object  Size  was  available  where  lines  only  given,  ratio  varies  wi  tli 

design.  INS  provided  detail  analysis  (available  in  original  FIELD  SITE 
DATA  on  file)  which  indicates  estimates  for  comparison  of  program  sizes 
will  virv.  Generally  BAL  produces  less  object  code  -  is  more  diff  ieult  to 
write  and  moaifv  -  than  FORTRAN. 
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support  f  OFP  flight  test  requirements  will  be  managed  by  the  SPO  (ASD/YPT) 

■  ’.null  PMRT  il  which  point  Ogden  ALC  will  assume  this  responsibility.  The  SPO 
pLaus  to  primarily  use  the  FSD  avionics  test  aircraft  (F-16A  No. 3,  serial 
number  73-0747)  for  this  task.  This  aircraft  is  equipped  with  an  avionics  data 
bus  chat  allows  all  traffic  on  the  MUX  bus  to  be  recorded.  These  software  testing 
tasks  will  be  accomplished  at  Edwards  AFB. 

The  QT&E  disposition  plan  (not  yet  formally  approved)  assigned  F-16A  No . 5 
(serial  number  75-0749)  to  Hill  AFB  for  OFP  support.  This  aircraft  is  to  be 
transferred  from  Edwards  in  October  1979.  F-16A  No. 5  will  require  additional 
instrumentation  in  order  to  record  MUX  bus  data.  Intermediate  and  depot  level 
support  of  the  instrumentation  and  the  reduction  of  avionics  data  will  be  accom¬ 
plished  at  the  AFFTC  subject  to  an  MOU  between  Ogden  ALC  and  AFFTC. 

It  is  anticipated  that  the  F-16  flight  test  aircraft  used  for  OFP  flight 
testing  will  carry  instrumentation  which  will  include  capability  for  data 
recording.  The  addition  of  sophisticated  instrumentation,  on  the  range  and  the 
aircraft,  will  provide  a  facility  to  test  and  evaluate  air  combat  maneuver in  , 
air-to-station/air-to-air  weapons  release,  gunnery,  and  navigational  systems. 


Approximately  90  flight  hours  per  block  change  are  forecast  for  OFP  testing. 
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PROGRAMMER  TRAINING: 

F-16  systems  familiarization  for  software  support  systems  engineering/ 
programming  personnel  will  be  required.  These  courses  will  establish  a  basic 
knowledge  in  avionics  navigation/weapon  release  functions  as  mechanized  in  the 
digital  avionics  system.  Specialized  courses  for  software  support  systems 
simulation  personnel  are  also  required.  This  training  will  familiarize  and 
establish  basic  skills  in  the  development  and  operation  of  minicomputer  systems, 
peripheral  equipment,  real-time  avionics  models,  simulation  software  executive 
routines,  and  data  reduction/analysis  information  processing.  Management  courses 
in  OFF  support  systems  will  establish  management  visibility  in  the  many  disciplines 
whose  composite  structure  is  an  operating  OFP  support  system.  These  courses  will 
include  such  topics  as  V&V  methodology,  configuration  management,  tactical  systems 
simulation  techniques,  etc.  Training  in  certain  areas  of  these  categories  will 
take  place  as  part  of  the  OFP  Independent  Assessment  activities  in  FSD;  however, 
the  training  will  still  be  required  for  those  additional  personnel  that  are  acquired 
during  the  transitional  phase.  The  F-16  Maintenance  Training  and  Transition  Plan 
produced  during  FSD  will  outline  specific  training  requirements.  The  phasing  of 
courses  will  be  optimized  to  reduce  the  impact  on  F-16  production  activities  during 
the  training  periods. 


USER  TRAINING: 

Plans  for  user  training  are  being  developed. 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  MAINTENANCE  HISTORY _  DATE:  31  October  1979 


DESCRIPTION  OF  NUMBERS  AND  TYPES  OF  MAINTENANCE  ACTIONS  PERFORMED  EACH  YEAR 
SINCE  PMfiT 


The  following  P,re-PMRT  F-16  OFP  changes  were  cited  by  MMECA  personnel: 


Change  ID 

Date 

OFP 

Description 

ECP  042R 

1977 

INS 

Incorporate  automatic  magnetic 
variation  (MAGVAR) 

Modification  of  two  cards 

Addition  of  two  ROM  chips 

1228  data  base  words  affected 

ACSN  484 

1/1977 

HUD 

Symbology  change  including  seven 
major  refinements 

Block  I 

HUD 

Use  of  fall  line  to  indicate 

10°  x  4°  Radar  Scan 

ECP  206 
(Block  II) 

HUD 

5  additions 

9  modifications 

ECP  153 

9/1978 

Radar 

Definition  of  configuration  update 
Retrofit  Plan,  and  schedule 

W  ECP  22 

4/1979 

Radar 

Correct  Problems 

W  ECP  23 

8/1979 

Radar 

Correct  Problems 

W  ECP  30 

9/1979 

Radar 

Correct  Problems 

W  ECP  17R1 

Radar 

Upgjade  Radar  OFP 

Block  II 

SMS 

Code  design  updates 

Code  modification  for  POD  testing 
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PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  MAINTENANCE  COST  HISTORY 

I  YEARLY  COST  OF  MAINTAINING  PACKAGE: 


DATE:  31  October  1979 


The  table  below  summarizes  the  MMECA  effort  spent  directly  in  requirements 
evaluation  of  change  candidates  and  OFP  testing  of  change  items  for  F-16 
Block  II.  Reference:  Project  Analysis  Report  dated  25  August  1979. 

Projected 

Number  of  Original  Actual  Percent  Estimate 

Description  Changes /Tasks  Estimate  Resource  Time  Completed  to  Complete 


PDR  Support, 
Release  1A 

19 

522 

771  Hours 

100% 

771 

OFP  Test, 
Release  1C 

25 

2,876 

1,847 

58% 

3,173 

Requirements 
Evaluation 
Release  2E 

76  1,056  337 

(task  re-assigned  to  contractor) 

98% 

343 

OFP  Test, 
Release  2G 

22 

1,465 

279 

22% 

1,257 

Requirements 
Evaluation, 
Release  31 

4 

80 

- 

0% 

80 

Requirements 
Evaluation, 
Release  11 

65 

610 

900 

100% 

900 

TOTAL 

211 

6,609 

4,134  Hours 

6,524 

The  projected 

cost  budget 

is  shown  on 

pages  E-67  through 

F.-69 . 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  31  October  1979 


F-16  SOFTWARE  COST  SHARING  BUDGET 
TOTAL  COST  SUMMARY 


TOTAL  COSTS  ($  MIL) 


FY  '80 

FY  '81 

FY  '82 

Manpower 

4.03 

5.40 

5.89 

AISF  &  SSC 

.43 

2.31 

3.10 

ECP 

* 

* 

* 

TOTAL 

4.46 

7.7’ 

8.99 

*ASD/YP  (AFSC) 

Administered  Prior 

to  PMRT. 

PRO-RATA  COST  SUMMARY 

Number  of 
Aircraft 

PCT 

APPORTIONED  COST 

FY  '80  FY  ' 81 

($  MIL) 

FY  '82 

USAF 

650 

65.2 

2.91 

5.03 

5.86 

Belgium 

116 

11.6 

.52 

.89 

1.04 

Netherlands 

102 

10.2 

.45 

.79 

.92 

Norway 

72 

7.2 

.32 

.56 

.65 

Denmark 

58 

5.8 

.26 

.45 

.52 

TOTAL 

998 

100.0 

4.46 

7.71 

8.99 
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PREDICTIVE  SOFTWARE  COST  MOO  EL 


CONTINUATION  SHEET 


DATE:  31  October  1979 


F-16  SOFTWARE  COST  SHARING  BUDGET 


Manpower 


Total  Cost  ($  MIL) 


FY  '80 

FY  '81 

FY 

'82 

FY  '80 

FY 

'81 

FY  '82 

MMAR(SM) 

6 

6 

6 

.30 

. 

30 

.30  * 

MMET(AISF) 

6 

6 

6 

.30 

30 

.30  * 

(Flight  Test) 

3 

3 

3 

.15 

• 

15 

.15  * 

MMEC 

27 

27 

2 

7 

1.35 

i. 

35 

1.35  * 

MACT 

8 

18 

1 

8 

.  46 

i. 

04 

1.04  ** 

macp/l 

5 

15 

1 

5 

.29 

• 

87 

.87  ** 

ACDC 

17 

20 

2 

2 

.85 

i. 

00 

1.10  * 

CONTRACTOR 

Engr 

_5 

_ 6 

_1 

2  (1) 

.33 

. 

39 

.78  *** 

77 

101 

10 

9 

4.03 

5. 

40 

5.89 

*  Estimated  at  $50K/man  year 

**  Estimated  at  58K/man  year 

***  Estimated  at  65K/man  year 


Note  (1)  MMAR  -4 

(a)  Integ  Engr  (GD) 

(b)  AEB  Engr  (GD) 

(c)  RES  Engr  (WEC) 

(d)  AXS  Engr  (GD) 

(2)  MMET  -3 

(3)  MMEC  -5  (GD) 


Umtuatt 


CONTINUATION  SHEET 


PREDICTIVE  SOFTWARE  COST  MOO  EL 


F-16  SOFTWARE  COST  SHARING  BUDGET 


EQUIPMENT  MAINTENANCE 


Maintenance 
Cost  ($  MIL)  Cost  ($  MIL) 


DATS:  31  October 


Item 

Orig  Cost 

Maint  Factor 

FY  '80 

FY  '81 

FY  '1 

AEB 

4.03 

3.56 

.21 

.43 

.43 

DEC10 

1.32 

1.32 

.08 

.16 

.16 

DSS  (Phase  I) 

3.24 

1.08 

.03 

.13 

.13 

(Phase  II) 

2.33 

.78 

.09 

.09 

SMOP  TS 

2.50 

.83 

.10 

.10 

MDS  800 

.05 

.05 

.01 

.01 

RES 

1.00 

1.00 

.12 

.12 

AIS 

9.00 

9.00 

.81 

1.08 

HUD  TS 

2.50 

.83 

.10 

.10 

Flight  Test 
(FY  ’81) 

3.73 

1.24 

.15 

.15 

Flight 

Reduction 

.58 

.58 

.07 

.07 

ESS 

.08 

.08 

.01 

.01 

EPROM  Programmer 

.25 

.10 

.01 

.01 

.01 

ATPG 

5.64 

1.90 

.23 

Mini  DEMS 

.72 

.37 

.04 

S/W  Prep  Station 

’.58 

.28 

.02 

.03 

.03 

S/W  Repo  Station 

.18 

.18 

.02 

AISF  A/C,  Halon, 

400  Hz 

.17 

.17 

.02 

.02 

SUB  TOTAL 

37.90 

23.35 

.37 

2.24 

3.02 

UTILITIES 

.01 

.01 

.01 

SUPPLIES 

.01 

.01 

.02 

IBM  360  UTILIZATION 

.04 

.05 

.05 

TOTAL 

.43 

2.31 

3.10 

PREDICTIVE  SOFTWARE  COST  MODEL 


HISTORICAL  DATA  SOURCES 


Data  Base  Name 
Location 
Contact  Person 
Phone  Number 
General  Contents 
Period  Covered 

Data  Quality 


DATE: 31  October  1979 


F-16  Operational  Flight  Program 
OO-ALC /MMECA ,  Hill  AFB,  Utah 
Dave  Thorne 11 
(801)  777-7231 
Manhours  by  task 

The  data  base  currently  contains  only  manhours 
associated  with  V&V  of  contractor-generated 
changes.  00-ALC/MMECA  will  not  begin  generating 
changes  until  1981. 

Good  detail  on  expenditure  of  manhours  to  task 


PREDICTIVE  SOFTWARE  COST  MODEL 


RECOMMENDATIONS  RE  SOFTWARE  SUPPORT  COST  PREDICTING _ DATE:  31  October  1979 

RESPONDENT:  Dave  Thornell 

o  What  existing  airplane  will  it  be  most  like? 

o  How  much  ROM?  (Use  for  infrequently  changed  programs.) 

o  HOL  versus  AL  -  Does  not  make  much  difference  price-wise.  FCC  uses  JOVIAL  HOL 
which  is  easier  to  modify  (the  OFP)  and  provides  good  visibility  of  change/ 
structure.  Software  interfaces  have  significant  cost  impact. 

o  Number  of  aircraft  supported  -  not  a  major  cost  factor. 

o  What  functions  will  the  system  have?  What  mission-support  automated  features 
(e.g.,  BIT)?  Will  there  be  off-line  systems  (e.g.,  mission  profile 
generators,  BIT  analysis)? 

o  How  much  software  will  be  assigned  to  the  system  manager  via  the  item 
manager? 

o  Is  it  being  built  by  somebody  who  supports  another  system  I'm  using? 

o  Is  the  ALC  required  to  support  OT&E  requirements  from  AFTEC? 

o  When  is  PMRT  in  relation  to  production? 

o  Will  the  whole  system  transfer,  or  just  certain  configurations? 


PREDICTIVE  SOFTWARE  COST  MODEL 


RECOMMENDATIONS  RE  SOFTWARE  SUPPORT  COST  PREDICTING 

RESPONDENT:  Dave  Thornell 

o  What  existing  airplane  will  it  be  most  like? 
o  How  much  ROM?  (Use  for  infrequently  changed  programs.) 


31  October  1979 


o  HOL  versus  AL  -  Does  not  make  much  difference  price-wise.  FCC  uses  JOVIAL  HOL 
which  is  easier  to  modify  (the  OFP)  and  provides  good  visibility  of  change/ 
structure.  Software  interfaces  have  significant  cost  impact. 

o  Humber  of  aircraft  supported  -  not  a  major  cost  factor. 

o  What  functions  will  the  system  have?  What  mission-support  automated  features 
(e.g.,  BIT)?  Will  there  be  off-line  systems  (e.g.,  mission  profile 
generators,  BIT  analysis)? 

o  How  much  software  will  be  assigned  to  the  system  manager  via  the  item 
manager? 

o  Is  it  being  built  by  somebody  who  supports  another  system  I'm  using? 

o  Is  the  ALC  required  to  support  OT&E  requirements  from  AFTEC? 

o  When  is  PMRT  in  relation  to  production? 

o  Will  the  whole  system  transfer,  or  just  certain  configurations? 
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PREDICTIVE  SOFTWARE  COST  MOOEL 


CONTINUATION  SHEET-  Acronyms 


OATS:  31  October  1979 


CADC 

CDR 

CEP 

C/I 

CM 

CPCI 

CPCSB 

CPIN 

CRISP 


ECP 

ECS 

EPROM 

EM 


Data  Automation 

Avionic  Depot  Test  Station 

Avionic  Equipment  Bay 

Avionic  Intermediate  Shop 

Avionic  Integration  Support  Facility 

Aircrew  Training  Device 

Automatic  Test  System 

Central  Air  Data  Computer 
Critical  Design  Review 
Contractural  Engineering  Proposal 
Computer /Inertial 
Configuration  Management 
Computer  Program  Configuration  Item 
Computer  Program  Configuration  Sub-Board 
Computer  Program  Identification  Number 
Computer  Resources  Integrated  Support  Plan 

Display/Indicator 
Deficiency  Reports 
Dynamic  System  Simulator 
Dynamic  Test  Station 

Engineering  Change  Proposal 
Embedded  Computer  System 
Erasable-Programmable  Read  Only  Memory 
Electronic  Warfare 

Fire  Control  Computer 
Fire  Control  Radar 
Foreign  Military  Sales 

General  Purpose  Computer  Complex 

Head-up  Display 

In  Accordance  With 
Item  Manager 
Inertial  Navigation  Set 

Line  Replaceable  Unit 

Multinational  Configuration  Control  Board 
Multinational  Configuration  Management  Plan 
Material  Deficiency  Review  Board 
Material  Improvement  Program 
Memorandum  of  Understanding 
Multiplex 
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CONTINUATION 


OCP 

OFP 

OFT 

01 

OPR 

O/SCMP 

PCA 

PDR 

PMRT 

P/P 

PROM 

RAM 

REO 

RF 

ROM 

SAMT 

SM 

SMS 

SOW 

SPO 

SRR 

SRU 

TCTO 

UUT 

V&V 


SHEET  -  Acronyms 


Organic  Change  Proposal 
Operational  Flight  Program 
Operational  Flight  Trainer 
Operating  Instruction 
Office  of  Prime  Responsibility 

Operational/Support  Configuration  Management  Plan 

Physical  Configuration  Audit 
Preliminary  Design  Review 
Program  Management  Responsibility  Transfer 
Processors /Pneumatics 
Programmable  Read-Only  Memory 

Random  Access  Memory 
Radar/Electro-Optical  Display 
Radio  Frequency 
Read-Only  Memory 

Simulated  Aircraft  Maintenance  Trainer 

System  Manager 

Stores  Management  Set 

Statement  of  Work 

System  Program  Office 

Software  Requirement  Review 

Shop  Replaceable  Unit 

Time  Compliance  Technical  Order 

Unit  Under  Test 

Validation  and  Verification 


APPENDIX  F 


F-15/WRALC  DETAILED  DATA 
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PREDICTIVE  SOFTWARE  COST  MODEL 
FIELD  EVALUATION  REPORT 


GENERAL  SOFTWARE  PACKAGE  DESCRIPTION 


DATE:  15  Feb.'8n 


ALC: 


WR 


WEAPON  SYSTEM: 


F-15 


SOFTWARE  PACKAGE:  See  description  on  pages  F-2  through  F-4. 


PERSONNEL  CONTACTED: 
Charles  Singleton,  MMEC 
Herschel  Vandiver,  MMEC 
Henry  McGirt,  MMECD 
Bob  Anderson,  MMECD 
Pete  Cerny,  MMECV 


SOFTWARE  PACKAGE  CHARACTERISTICS: 


SIZE: 

LANGUAGE: 

CC 

16K 

Assembly 

RDP 

24P  (96k  is  planned  for  June  1980. 

This  includes  the  PSP). 

Assembly 

APPLICATION: 

General  navigation 
and  flight  control 

Target  acquisition  and  fire  control 

COMPLEXITY: 

Not  very  complex, 
structured  design  , 

Very  complex 

YEAR  DEVELOPED: 

1970 

1972 

DEVELOPER: 

McAir 

Hughes 

COMMENTS 

Inadequate  visibility  into  program 

HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS: 

CC 

RDP 

MANUFACTURER: 

IBM 

Hughes 

MODEL  NUMBER/OESIGNATOR:  AF-1 

HCM-231 

WORD  SIZE: 

32  bit 

24  bit 

MEMORY  SIZE: 

16K 

24K  (the  planned  96k  memory  will 
have  <v30k  spare  words) 

MEMORY  FILL: 

70S 

Full 

WEAPON  SYSTEM  USE: 

NUMBER  OF  USERS:  400  ;  729  planned 

locations  OF  USERS:  Worldwide 


FREQUENCY  OF  USE: 


daily 


INTERVIEWERIS): 


R.B.  Walna.  C.  L.  Foreman.  A.  P.  Banq« 
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CONTINUATION  SHEET 


DATE: 


15  Feb.  '80 


F-15  Avionics  System  Overview  -  The  F-15  uses  an  Integrated  system  in 
which  twelve  avionics  subsystems  Interface  with  the  Central  Computer  (CC) 
via  redundant  multiplex  (MUX)  busses.  The  Central  Computer  performs  primarily 
mission  oriented  calculations,  while  computations  and  processing  generic  to 
peripheral  avionic  subsystems  are  accomplished  (insofar  as  possible)  within 
the  subsystems  themselves.  Thus,  the  Central  Computer  accepts  inputs  calculated 
by  peripheral  avionics  devices,  performs  mission  oriented  calculations  and 
outputs  results  to  the  appropriate  subsystems.  The  F-15  Radar  System,  Air  Data 
System,  Lead  Computing  Gyro,  Inertial  Navigation  Set  and  Radar  Warning  Receiver 
of  the  Tactical  Electronics  Warfare  System  have  self-contained  computers,  ^e 
Radar  Warning  Receiver  (RWR)  and  Internal  Countermeasures  Set  (ICS),  part  of  the 
Tactical  Electronic  Warfare  System,  the  Central  Computer,  and  Radar  Processor 
are  the  only  programmable  devices  on  the  F-15.  The  RWR  has  a  data  processor  and 
the  ICS  has  a  read  only  memory  which  will  be  used  as  a  back  up  if  the  RWR  has 
a  malfunction.  Also,  the  Heads-Up  Display  and  Vertical  Situation  Display 
have  self-contained  symbol  generators.  In  addition,  each  avionics  device  which 
interfaces  with  the  Central  Computer  has  a  self-contained  analog-to-dlgital  and 
digital-to-analog  conversion  unit  so  that  all  interfaces  between  the  Central 
Computer  and  peripheral  avionics  are  digital.  Should  communication  between  the 
Central  Computer  and  Radar  be  Interrupted,  the  Radar  Data  Processor  via  an 
independent  multiplex  bus  can  provide  control  of  the  radar  to  sustain  a 
capability  to  continue  combat.  Although  this  discussion  portrays  relatively 
simple  Interfaces,  the  fact  remains  that  integration  is  extensive  and  performance 
of  the  F-15  Weapon  System  is  directly  dependent  on  the  proper  functioning  of 
the  Central  Computer  and  Radar  Data  Processor  Operational  Flight  Programs. 

Figures  F-l  and  F-2  are  block  diagrams  of  the  CC  and  RDP  Interfaces,  respectively. 

Central  Computer  -  The  F-15  CC  is  an  IBM  developed  general  purpose,  stored 
program,  simplex,  high  speed,  digital  machine  designated  the  AP-1.  The  CC  memory 
is  random  access,  non-volatile  core  with  a  capacity  of  16,384  34-bit  words 
(2  parity)  which  is  expandable  to  24,576  words. 

Central  Computer  OFP  (CCOFP)  -  The  CCOFP  directs  the  computer  to  solve  the 
various  F-15  related  problems.  The  CCOFP  is  divided  into  eight  program  modu1es 
as  listed  below.  The  modular  sturcture  of  the  CCOFP  allows  for  considerable 
flexibility  in  accomplishing  program  changes  or  adding  additional  functions. 

CCOFP  Modules 

Executive  (EXEC) 

Air-to-Air  (A/A) 

Air-to-Ground  (A/G) 

Navigation  (NAV) 

Flight  Director  (FD) 

Control  and  Display  (C&P) 

Computer  Self  Test  (CST) 

Math  Subroutine  (SR) 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  15  Feb.  '80 


Radar  Data  Processor  (RDP)  -  The  RDP  is  a  Hughes  developed  general  purpose 
computer  which  provides  the  local  point  for  radar  set  operation  as  well  as  for 
interface  with  other  avionics  equipment.  The  RDP  consisits  of  a  processor,  a 
special  input/output  unit  and  integrated  power  supply.  Three  RDP  configurations 
are  planned: 

a.  Core  Memory  -  A  16,384  word  device  using  core  memory.  This  unit  was 
incorporated  in  all  production  aircraft  prior  to  ECP  900  (approx,  mid  1978),  and 
is  scheduled  to  be  eliminated  via  retrofit  during  1980. 

b.  Solid  State  Memory,  24k  -  A  24,  576  word  device  using  solid  state 
Electrically  Alterable  Read  Only  Memory  (EAROM)  for  non-volatile  storage  and  solid 
state  random  Access  Memory  for  scratch  pad  use.  This  unit  is  scheduled  for  use 

in  all  F-15  A  and  B  aircraft  beginning  with  production  aircraft  in  mid  1978.  It 
will  also  be  used  in  early  C  and  D  model  aircraft,  but  will  be  replaced  by  the 
96  K  unit. 

c.  Solid  State  Memory,  96  K  -  A  98,  304  word  device  also  using  solid  state 
memory.  The  added  memory  will  be  used  as  non-volatile  program  storage  for  the 
Programmable  Signal  Processor  LRU  as  well  as  for  RPP  program  expansion.  This  unit 
will  be  incorporated  in  all  C  &  D  model  aircraft  beginning  with  production  with 
models  in  1980. 

RDP  Operational  Flight  Program  (RDPOFP)  -(I)  The  Acquisition,  (2)  Track  and 
(3)  Built-in-Test  (BIT) .  For  purposes  of  describing  the  overall  structure  of  the 
program,  the  RDPOFP  can  be  divided  into  eight  program /modules,  shown  below,  and 
a  data  base.  < . 


RDPOFP  Modules 

Power  Up 

Antenna  Control 

Search  and  Acquisition 

Track 

Displays 

BIT 

Executive  Module 
Subroutine 


Programmable  Signal  Processor  (PSP)  -  The  PSP  is  a  Hughes  developed  special 
purpose  computer  which  provides  digital  processing  of  the  radar  returns.  The 
program  for  the  PSP  is  loaded  and  stored  with  the  RDP  program  and  thus  is  part  of 
the  RDPOFP.  The  PSP  has  no  OFP  of  its  own. 
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DATE: 


15  Feb.  '80 


CENTRAL  COMPUTER 
IBM  AP  -  1 
16  KX  32  BIT* 


OPERATIONAL  FLIGHT 
PROGRAM  MODULES 

•  EXECUTIVE 

•  AIR-TO-AIR 

•  AIR-TO-GROUND 
o  NAVIGATION 

o  FUCIir  DIRECTOR 
o  CONTROL  &  DISPLAYS 
o  SELF  TEST 
a  sun  ROUTINES 


MUX  BUS  fl 


RADAR 

(DATA 

PROC.) 

ATT. 

HEAD 

REF. 

SET 

AIR 

DATA 

COMP. 

NAV. 

CONT. 

IND. 

HEADS 

UP 

DISP. 

SIGNAL 

DATA 

REC 

1  1 

TL 

BUS  13, 

|  BUS  | Z\ 

wmmm 

■  ■ 

IS  HUES 

SB 

■ 

■ 

TEWS 

a 

wmm 

i 

1 

I 

B 

1 

(RADAR 

1 

IIORZ. 

LEAD 

VERT. 

I 

IN. 

B 

WARN. 

I 

SIT. 

I 

I 

COMP. 

I 

SIT. 

I 

MLAS. 

B 

1 

RCVR 

IND. 

I 

mm 

1 

GYRO 

1 

DISP. 

I 

UNIT 

B 

I 

PROC. ) 

1 

1 

UK 

1 

1 

1 

BUS  14 

- — l 


•EXPANDABLE  TO  24  K 


F-15  AVIONICS  SYSTEM  (CENTRAL  COMPUTER) 


Figure  F-l 


RADAR  DATA  PROCESSOR  (RDP) 
Figure  F-2 
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MAINTENANCE  AGENCY  PERSONNEL 


ALC:  WR 


15  Feb*  '80 


OFFICE  SYMBOL: 


KEY  PERSONNEL/OGRANIZATION: 
MMEC  -  Charles  Singleton 

MMECD  -  Herschel  Vandiver 
MMECE  -  Jay  Hedge 
MMECV  -  Chester  Sherrill 
MMECA  Don  Purvis 
MMECT  -  Charlie  Walker 


TOTAL  ASSIGNED  PERSONNEL  (NUMBER  &  TYPE): 


Function 


F-15  Personnel 


MMECD  OFP  Design  20 

MMECV  Validation  &  13 

Verification, 

MMECE  Avionics  Integration  &  13 

Support 

MMECA  Avionics  Test  Acq.  5 

51 


TOTAL  PACKAGES  MAINTAINED  (NUMBER  &  TYPE): 
Two  F-15  OFP 's :  CC  and  RDP 
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Total  MMEC  manning  requirements  as 

of  30  September  1980 

i  are  as 

follows : 

Svstem 

OFP 

ATE 

System 

OFP 

ATE 

F-15 

63 

9 

Misc. 

.7 

PAVETACK 

16 

FSG-70 

5.5 

JTIDS 

13 

1 

AIM  4/9 

1 

VATS 

1 

A-7D 

1 

HARM 

1 

A-10 

2 

EAR 

1 

B-52 

.5 

7 

HAST 

.2 

C-5 

.5 

GPS 

5 

1 

C-130 

.25 

.5 

AMRAAM 

0 

C-141 

.5 

HMS 

1 

E-3A  AWACS 

.2 

3 

HH-53H 

.2 

AFCAT-COM 

2 

CSD 

1 

F-4 

1 

1 

DAIS /IDA 

-o 

F-105 

1 

SAS 

.25 

F-106 

2 

LOCUST 

.2 

F-lll 

1 

6 

TOTAL 

106 

44 
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DESCRIPTION  OF  WORK  PACKAGE  DISTRIBUTION,  INCLUDING  RESPONSIBILITIES  AND  DEGREE  OF 
SPECIALIZATION  OF  AF/CS/CONTR  PERSONNEL 

MMEC  has  been  reorganized  as  below.  To  data  manning  is  totally  civil 
service /AF. 


MMECT  —  ATE  Support 

MMECA  -  ATE  Acquisition 

MMECV  -  Validation  &  Verification 

MMECE  -  AISF  Equipment  &  Support 

MMECD  -  Weapon  System  Integration 

MMECDF-  F-15  OFP  Design 
Radar 

Central  Computer 
MMECDA  -Acquisition  Support 
Pavetack 
JTIDS 
GPS 


MMECDM  -Management 
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WR-AXC  is  planning  to  build  an  Engineering  Data  Management  System  (pt»MS)  to 
satisfy  project  control,  change  control,  and  configuration  management  requirements 
for  avionics  systems.  The  Project  Control  function  in  FDMS  shall  provide  MMFC 
management  with  an  automatic  means  of  tracking  manpower  estimates  versus  actual 
usage  over  the  lifetime  of  the  set  of  engineering  projects  within  a  Branch,  as 
well  as  all  other  personnel  charges  (leave,  training,  etc.) 

Typical  reports  include: 

•  An  "ECS  Change  Cost  Summary '(Figure  F-3)  shall  be  generated  based  on  the 
user's  request  and  specification  of  an  FCS  Change  Block. 

•  An  'AISF  Change  Cost  Summary '(Figure  F-4)  shall  be  generated  based  on  the 
user's  request  and  specification  of  an  AISF  Change  Block. 

•  A  Final  Project  Status  Report  shall  be  generated  upon  completion  of  the 
project,  A  project  shall  be  marked  closed  after  all  employees  assigned  to 
that  project  have  been  closed  out  and  this  fact  is  recorded  in  the  data 
base.  An  example  oi  the  type  of  data  to  be  provided  is  presented  in 
Figure  F-5. 
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FINAL  PROJECT  STATUS 

REPORT 

PROJECT  NAME: 

DATE 

OPENED  / 

/ 

PROJECT  NO: 

DATE 

DUE  /  / 

PRODUCTION  CODE: 

DATE 

CLOSED  / 

/ 

STANDARD: 

PURPOSE: 

MIP  NO: 

MME  OPENDATE 

/  / 

ALC  OPENDATE 

/  / 

MME  DUE  DATE 

/  J- 

— 

ALC  DUE  DATE 

/  / 

WORK 

EST 

ACT 

ENGINEERS  ASSIGNED 

UNIT 

HOURS 

HOURS 

TOTALS 


Figure  F-5.  Example  of  Final  Project  Status  Report 
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SUPPORT  PHILOSOPHY: 

The  following  information  is  extracted  from  MMEC  operating  instruction  800-14. 

1.  GENERAL:  A  summary  sequence  of  events  relative  to  tasks  and  documentation 
requirements  is  presented  in  Figure  F-6.  (No  absolute  time  division  is  intended.) 

2.  CHANGE  BLOCKING:  OFP  design,  and  validation  and  verification  personnel,  will 
review  the  list  of  user  prioritized  change  requests  and  select  requests,  based 

on  change  priorities  and  changing  organization  staff  power,  for  inclusion  in 
organic  or  contractor  block  change (s).  Coordinate  change  candidates  with  the 
using  organization. 

a.  Contractor  Change.  For  changes  not  considered  organically  feasible 
contractor  assistance  is  obtained. 

b.  Organic  Change.  For  organic  changes,  OFP  design  personnel  will  review 
mission/system  requirements  as  relates  to  identified  block  changes. 

(1)  Emergency  Change.  Emergency  changes  will  take  precedence  over  routine 
changes  and  should  be  handled  in  accordance  with  r  stablished  procedures. 

CHANGE  CONTROL  METHODS: 

FORMAL  OR  INFORMAL:  Formal 


CHANGE  REVIEW  PROCESS:  See  pages  F"18  through  F-24 


CONFIGURATION  IDENTIFICATION  METHODS:  See  pages  F-18  through  F-24 


CONFIGURATION  CHANGE  CONTROL  METHODS:  See  pages  F-18  through  F-24 


CONFIGURATION  STATUS  ACCOUNTING  METHODS:  See  PaSe  F_19 


SOFTWARE  LIBRARY  CONTROL  PROCEDURES:  See  page  F-17 
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(2)  Preliminary  System  Specification.  OFP  design  personnel  will  prepare 
a  preliminary  system  specification  change  or  certify  no  change  required. 

(3)  OFP  Technical  Conference.  CM  personnel  will  schedule  an  OFP  Technical 
Conference.  A  list  of  topics  to  be  discussed  is  presented  on  pages 

(4)  Change  Approval.  Configuration  management  personnel  will  submit  the 
proposed  change  block,  with  AFLC  Form  75  prepared  by  the  CPSP,  to  the  CPCSB/CCB  for 
approval.  Technical  assistance  will  be  provided  by  OFP  design  personnel. 

3.  PRELIMINARY  DESIGN:  OFP  design  personnel  will  proceed  with  preliminary  design 
of  the  OFP  after  appropriate  change  approval. 

a.  Final  System  Specification.  Prepare  a  final  system  specification  change  if 
required.  Sign-off  by  the  systems  engineer  (SM-IM),  OFP  design  engineer  and  the 
validation  and  verification  engineer  after  the  Initial  Design  Review,  constitutes 
approval  of  a  system  specification  change. 

b.  Preliminary  Development  Specification.  OFP  design  personnel  will  review  the 
development  specification  and  prepare  a  preliminary  development  specification  change 
or  certify  no  change  required. 

c.  Preliminary  Product  Specification.  OFP  design  personnel  will  prepare  a 
preliminary  product  specification  change. 

d.  Preliminary  Development  Test  Plans.  OFP  design  personnel  will  prepare  pre¬ 
liminary  computer  program  configuration  item  and  computer  program  component 
development  test  plans  presented  on  page  F-31. 

e.  Initial  Design  Review.  CM  personnel  will  schedule  an  Initial  Design  Review. 

A  list  of  topics  to  be  discussed  is  presented  on  page  F-25. 

f.  System  Specification  Change  Control.  The  Modification  Request  (MR)  form 
will  be  used  to  request  changes  to  the  system  specification  after  formal  approval. 

4.  DETAILED  DESIGN:  OFP  design  personnel  will  proceed  with  detailed  design  after 
Japproval  of  the  system  specification. 

a.  Final  Development  Specification.  Prepare  a  final  development  specification 
change  if  required.  Sign-off  by  the  CPCI  lead  engineer  and  validation  and 
verification  engineer  after  the  Detail  Design  Review  constitutes  approval  of  a 
development  specification  change. 

b.  Update  Product  Specification.  Perform  detailed  design  to  routine  level, 
with  flow  charts,  and  update  the  product  specification. 

c.  Update  Development  Test  Plans.  Update  the  development  test  plans  to 
comply  with  the  development  specification. 

d.  Validation  Test  Plans.  Validation  and  verification  personnel  will  prepare 
validation  test  plans.  The  general  contents  of  the  plans  are  presented  on  page 

e.  Preliminary  User's  Technical  Manuals.  OFP  design  personnel  will  prepare 
preliminary  change  sheets  to  the  user's  technical  manuals  if  affected. 
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f.  Preliminary  Computer  Programming  Manuals.  OFP  design  personnel  will  prepare 
preliminary  change  sheets  to  the  computer  programing  manual  if  affected. 

g.  Preliminary  Development  Report.  OFP  design  personnel  will  prepare  a 
preliminary  development  report.  The  general  contents  of  the  report  are  presented 
on  page  F-31 . 

h.  Detail  Design  Review.  CM  personnel  will  schedule  a  Detail  Design  Review.  A 
list  of  topics  to  be  discussed  is  presented  on  page  F-26. 

i.  Development  Specification  Change  Control.  The  MR  form  will  be  used  to 
request  changes  to  the  development  specification  after  formal  approval. 

5.  CODE  AND  DEVELOPMENT  TEST;  OFP  design  personnel  will  proceed  with  detailed  coding 
and  development  testing  after  approval  of  the  development  specification  change. 

a.  Development  Library.  OFP  design  personnel  will  copy  the  save  tape  (source 
code)  from  the  last  OFP  release  into  the  development  library  and  modify  the  source 
code  to  incorporate  the  addendum,  if  any,  from  the  last  release.  Assemble  the  new 
source  and  test  sufficiently  to  be  confident  of  a  correctly  executing  OFP.  This 
new  source  becomes  Baseline  A  for  the  current  change  cycle.  Perform  all  coding  and 
development  testing  using  the  development  library. 

b.  Development  Test  Procedures.  OFP  design  personnel  will  prepare  development 
test  procedures.  The  general  contents  of  the  procedures  are  presented  on  page  F-32. 

c.  Validation  Test  Procedures.  Validation  and  verification  personnel  will  prepari 
validation  test  procedures.  The  general  contents  of  the  procedures  are  presented  on 
page  F-32. 

d.  Flight  Test  Plans.  Validation  and  verification  personnel  will  prepare  flight 
test  plans.  The  general  contents  of  the  plans  are  presented  on  page  F-32. 

e.  Final  Development  Report.  Prepare  a  final  development  report. 

f.  Master  Tape.  OFP  design  personnel  will  generate  a  new  baseline  master  copy 
of  the  OFP  relocatable  binary  code  or  magnetic  tape. 

g.  Save  Tape.  OFP  design  personnel  will  generate  a  save  copy  of  the  OFP  source 
code  on  magnetic  tape. 

h.  Transfer  Letter.  OFP  design  personnel  will  prepare  a  transfer  letter  to 
the  V&W  section  at  completion  of  development  testing.  The  contents  of  the  letter 
are  presented  on  page 

i.  Software  Change  Control.  The  MR  form  will  be  used  for  reporting  software 
problems  after  the  date  of  the  transfer  letter. 

(1)  Problem  Solution.  OFP  design  personnel  will  analyze  the  problem,  modify 
source  instructions  or  make  machine  code  patches  as  required,  perform  testing  as 
required,  indicate  action  taken  on  the  MR  and  sign  off  on  the  MR. 
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(2)  New  Baseline /Addendum.  OFP  design  personnel  will  produce  or  magnetic 
tape,  a  new  baseline  OFP  or  an  updated  addendum. 

(3)  Documentation  Changes.  Review  the  need  for  changes  to  the  development 
specification,  product  specification,  validation  test  procedures,  etc. 

6.  CPCI  VALIDATION  TEST:  After  receipt  of  the  transfer  letter,  V&V  personnel  will 
proceed  with  CPCI  ground  validation  testing  using  the  baseline  and  addendum  if 
applicable,  as  identified  in  the  transfer  letter. 

a.  Preliminary  Technical  Report.  Validation  and  verification  personnel  will 
prepare  a  preliminary  technical  report.  The  general  contents  of  the  report  are 
presented  on  page  F-32. 

b.  Flight  Test  Procedures.  Validation  and  verification  personnel  will  prepare 
flight  test  procedures.  The  general  contents  of  the  procedures  are  presented  on  page 

c.  Final  Product  Specification.  Prepare  a  draft  of  the  final  product  specifica¬ 
tion  changes. 

d.  Final  User's  Technical  Manual.  Prepare  a  draft  of  the  final  user's  technical 
manual  change. 

e.  Final  Computer  Programming  Manual.  Prepare  a  draft  of  the  final  computer 
programming  manual  change. 

f.  Validation  Test  Review.  CM  personnel  will  schedule  a  validation  test  review. 
A  list  of  topics  to  be  discussed  is  presented  on  page 

7.  USER  AND  V&V  FLIGHT  TEST:  After  successful  completion  of  the  Validation  Test 
Review,  V&V  personnel  will  proceed  with  flight  testing  as  required. 

a.  User  Copy.  Validation  and  verification  personnel  will  send  a  copy  of  the 
OFP  master  tape  and  latest  addendum,  if  appropriate,  reproduced  on  the  appropriate 
medium,  to  the  using  organization  when  a  hardware  change  was  not  involved. 

b.  Flight  Testing.  Load  flight  computers  from  a  copy  of  the  master  tape  and 
latest  addendum,  if  appropriate,  and  perform  flight  testing. 

c.  Change  Control.  Report  software  problems,  encountered  during  flight  testing, 
to  OFP  design  personnel  via  telephone  and  follow  up  with  a  completed  MR  Form.  The 
change  procedure  will  follow  that  established  for  CPCI  validation  testing. 

d.  Final  Technical  Report.  Prepare  a  final  technical  report. 

e.  Final  Product  Specification.  Prepare  the  final  product  specification  change 
sheets.  Sign-off  by  the  CPCI  lead  engineer  and  validation  and  verification  engineer 
after  the  Acceptance  Test  Review  constitutes  approval  of  a  product  specification 
change. 

f.  Final  User's  Technical  Manual.  Prepare  the  final  user's  technical  manual 
change  sheets. 
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g.  Final  Computer  Programming  Manual.  Prepare  the  final  computer  programming 
manual  change  sheets. 

h.  Version  Description  Document.  OFP  design  personnel  will  prepare  a  Version 
Description  Document.  The  contents  of  the  document  are  presented  on  page  F-33. 

i.  Acceptance  Test  Review.  CM  personnel  will  schedule  an  Acceptance  Test 
Review.  A  list  of  topics  to  be  discussed  is  presented  on  page  F-27. 

8.  BLOCK  CHANGE  REVIEW:  Submit  the  version  description  document;  index  to  CP1N; 
technical  report;  and  prepared  briefing,  when  requested,  to  the  CPCSB/CCB  for  review. 

a.  Disapproved  Change.  If  the  block  change  implementation  is  disapproved,  take 
the  change  back  in  the  change  process  as  far  necessary  to  correct  the  dificiency. 

b.  Approved  Change.  After  change  implementation  approval,  integrate  the 
documentation  changes  into  a  new  OFP  release. 

(1)  OFP  Release.  OFP  design  personnel  will  produce  duplicate  copies  of  the 
master  tape  and  latest  addendum,  if  appropriate,  recorded  on  the  appropriate  medium, 
for  release  to  the  using  command. 

(2)  Archival  Library.  Retain  archival  copies  of  the  master  tape,  latest 
addendum,  save  tape,  and  documentation  at  WR-ALC/MMEC.  Documentation  will  include 
the  system  specification,  development  specification,  product  specification,  version 
description  document,  development  report  and  technical  report. 
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1.  SCOPE.  These  pages  specify  the  minimum  configuration  management  requirements 
for  OFP  software  changes. 

2.  REVIEWS.  Configuration  management  personnel  will  schedule  and  co-chair 
the  technical  reviews  specified  within  this  document,  except  contractor  held 
reviews,  and  prepare  minutes  of  each  review. 

3.  DOCUMENTATION  LIBRARY.  Configuration  management  personnel  will  maintain 
an  archival  library  of  specified  OFP  related  documentation. 

4.  MODIFICATION  REQUESTS.  Modification  request  forms  and  control  numbers 
will  be  provided  by  configuration  management.  This  form  will  be  prepared  in  an 
acceptable  format,  and  in  accordance  with  the  following  instructions: 

a.  Date  -  Enter  the  date  MR  is  being  prepared. 

b.  Change  class  -  Enter  one  of  the  classes  defined  as  follows: 

(1)  A:  Testing  has  halted  due  to  the  problems  defined.  Fix  needed 
to  continue  testing. 

(2)  B:  Testing  is  continuing  with  problem  being  bypassed  or  test 
temporarily  skipped.  Fix  date  to  be  negotiated.  Fix  must  go  into  current 

release. 


(3)  C:  Desirable  change  or  typographical  error.  Does  not  interfere 
with  testing.  Fix  may  go  into  current  release  at  the  convience  of  the  designer. 

c.  MR  Number  -  Modification  request  control  number  to  be  entered  by  CM 
personnel. 

d.  System/OFP  Nomenclature  -  Enter  the  system  name  and/or  OFP  nomenclature 
as  needed  to  identify  the  OFP. 

e.  Problem  software  element  or  specification  -  Enter  the  nomenclature  of 
the  software  module  with  the  problem,  if  known,  or  the  problem  specification. 

f.  Date  problem  detected  -  Enter  the  date  the  problem  was  detected. 

g.  Date  fix  required  -  For  a  Class  B  change,  enter  the  latest  date  that 
a  fix  is  acceptable  in  order  to  complete  testing  on  schedule. 

h.  Temporary  action  taken  -  Briefly  describe  any  action  taken  to  resolve 
or  bypass  the  problem  and  may  be  of  help  to  the  development  section. 

i.  Problem  description  -  Briefly  describe  the  problem. 

j.  Proposed  solution  -  Optionally,  enter  a  brief  proposed  solution  to 
the  problem. 

k.  Signature  -  Signature  of  person  completing  the  MR  form. 
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l.  Office/Phone  -  Office  symbol  and  phone  extension  of  person  completing 
the  form. 

Items  m-q  of  the  form  are  to  be  completed  by  person  resolving  the  problem. 

m.  Software  element(s)  and/or  specification  changed  -  Enter  the  number  and 
nomenclature  of  the  element(s)  or  specification  changed. 

n.  Remarks  -  Enter  remarks  as  necessary  (e.g.  HR  cancelled.  Error  was  in 
test  procedures.) 

o.  Date  completed  -  Enter  the  data  the  software  development  tests  were  completed 
or  specification  changed. 

p.  Release/Version  -  For  changed  software,  enter  the  release  and  version  numbers 
of  the  new  OFP  or  addendum. 

q.  CM  signature  -  CM  personnel  will  sign  the  completed  form  and  forward  a  copy 
to  the  originating  office. 

5.  STATUS  ACCOUNTING.  Configuration  management  personnel  will  maintain  internal 
status  accounting  of  OFP  software  changes.  Monthly  status  reports  will  include 
the  following,  as  a  minimum: 

a.  OFP  Change  Cost  Summary  -  This  report  will  be  prepared,  for  each  change  block, 
in  an  acceptable  format  in  accordance  with  the  following  instructions: 

(1)  Document  Number  -  Enter  the  local  document  number  of  this  summary. 

(2)  Page  -  Enter  page  number  and  total  number  of  pages  in  this  summary. 

(3)  System  (Item)  -  Enter  the  nomenclature  of  the  host  system  or  item  of  the 
embedded  computer  system. 

(4)  OFP/Release  -  Enter  the  nomenclature  and  new  release  number  of  the  OFP 
included  in  this  block  change. 

(5)  Change  Requests  Being  Incorporated  -  Enter  the  numbers  of  all  change 
reports,  deficiency  reports  and  engineering  change  proposals  being  incorporated 
in  the  software  change. 

(6)  Week  Ending  -  Enter  the  date  of  the  end  of  week  when  cost  occurred. 
(Saturday  is  end  of  the  week.) 

(7)  Conractor  -  Enter  contractor  costs  as  occurring  on  the  date  of  a 
contract. 

(8)  Organic  -  Enter  costs  for  each  category  listed  and  total  of  the  organic 
categories. 

(9)  Cumulative  Total  -  Enter  the  cumulative  total  for  contractor  and  organic 
costs  for  each  reporting  period. 

(10)  Cumulative  costs  -  Enter  the  cumulative  cost  for  each  category  at  the 
end  of  each  listing.  This  is  the  last  entry  in  the  list. 
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b.  Configuration  Index.  This  report  will  be  prepared  and  maintained  for  the 
duration  of  the  change  block,  for  each  computer  program  configuration  item,  in  a 
a  format  that  is  illustrated  on  Pg.F-21  and  in  accordance  with  the  following 
instructions:  The  initial  issue  will  contain  only  (1)  Section  A,  identifying 
schedule  and  completed  milestone  data  pertaining  to  the  CPCI  and  (2)  Section  I, 
listing  the  basic  issue  of  the  development  specification. 

(1)  Document  Number  -  Enter  the  local  document  number  of  the  configuration 

index. 

(2)  Office  Symbol  -  Enter  the  office  symbol  of  the  office  responsible 
for  the  OFP  design. 

(3)  CPCI  Nomenclature  -  Enter  the  approved  nomenclature  of  the  CPCI. 

(4)  CPCI  Number  -  Enter  the  number  of  the  CPCI. 

(5)  System  -  Enter  the  title  and  number  of  the  system  of  which  the  CPCI  is 

a  part. 

(6)  Issue  Number  -  Enter  the  issue  number  of  the  index.  The  number  "1" 

is  assigned  to  the  first  issue  of  each  change  block;  subsequent  issues  are  numbered 
consecutively. 

(7)  Date  -  Enter  the  publication  date  of  the  given  index  issue. 

(8)  Processor  Signature  -  Signature  of  person  processing  the  index  to  be 
entered  after  last  issue  before  the  index  is  submitted  to  the  review  board  for 
.implementation  approval. 

(9)  Supervisor  Signature  -  Signature  of  processor's  supervisor  tc  be  entered 
after  last  issue  before  the  index  is  submitted  to  the  review  board  for  implemen¬ 
tation  approval. 

(10)  Table  of  Contents  -  Prepare  a  table  of  contents  at  the  front  of  the 
index  following  the  data  contained  in  the  blocks  previously  described.  Entries  will 
be  added  to  the  contents  at  the  time  a  new  section  is  added  to  the  Configuration 
Index.  The  page  number  will  identify  the  first  page  of  each  section  and  each  of 
the  two  parts  of  a  section. 

c.  Configuration  Item  Development  Record  -  Section  A  -  This  section,  a  part 
of  the  index,  will  be  prepared  in  an  acceptable  format  and  in  accordance  with  the 
following  instructions: 

(1)  CPCI  Number  and  Nomenclature  -  Enter  the  number  and  approved  name  of  the 
CPCI  as  it  appears  on  the  front  cover  of  the  CPCI  development  specification. 

(2)  System  Specification  Number  and  Date  -  Enter  the  number  of  the  system 
specification  and  date  of  last  change. 
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Document  Number: 

Office  Symbol: 

CPCI  Nomenclature: 

CPCI  Number: 

System: 

Issue  Number: 

Date: 


Processor  Signature: 

Supervisor  Signature: 

TABLE  OF  CONTENTS 

PAGE 
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(3)  Development  Specification  Number  and  Dates  -  Enter  the  number  of  the 
development  specification,  the  date  of  last  change,  and  the  date  it  was  accepted 
as  an  approval  change. 

(4)  Product  Specification  Number  and  Dates  -  Enter  the  number  of  the  product 
specification,  the  date  of  last  change,  and  date  it  was  accepted  as  an  approved 
change. 

(5)  Milestones  -  For  each  indicated  milestone  event,  enter  the  date  scheduled  for 
for  the  event  at  the  time  of  initial  issue  of  the  index.  If  rescneduling  occurs, 

enter  each  new  date  under  the  original  in  sequence,  retaining  all  previous  dates. 

Enter  the  date,  followed  by  a  "c* ,  on  which  the  event  is  actually  accomplished. 

(6)  Test  Documents  -  Enter  the  document  number,  title  and  date  of  issue 
of  all  CPCI  test  plans,  test  procedures  and  test  reports. 


I  manuals . 


(7)  Technical  Manuals  -  Enter  the  number,  title  and  date  of  change  of  all 


of  issue. 


(8)  Version  Description  Document  -  Enter  the  document  number,  title  and  date 


d.  Configuration  Item  Development  Record  -  Section  I  -  This  section,  a  part  oi 
the  index,  will  be  prepared  in  an  acceptable  format  and  in  accordance  with  the 
following  instructions: 

(1)  Number  -  Enter  the  number  of  the  development  specification. 

(2)  Date  -  Enter  the  date  of  the  approved  issue  of  the  development  specifica¬ 
tion. 

(3)  Modification  Request  Number  -  Enter  the  numbers  of  all  MPs  written 
against  the  development  specification  which  have  been  resolved.  MRs  will  be  removed 
after  one  issue  of  the  report. 

(4)  Remarks  -  Enter  a  few  words  describing  the  MRs. 

(5)  MR  Number  -  Enter  the  numbers  of  all  MRs  written  against  the  development 
specification  not  yet  resolved  at  the  date  of  this  index  issue. 

(6)  Class  Change  -  Enter  class  of  change  specified  on  the  MR. 

(7)  Date  Issued  -  Enter  the  date  that  the  MR  was  issued. 

(8)  Due  Date  -  Enter  the  date  solution  is  due  for  Class  B  MRs. 

(9)  Remarks  -  Enter  a  few  words  description  for  the  MR. 

e.  Configuration  Item  Development  Record  -  Section  II  -•  This  section,  a  part  of 
the  index,  will  be  added  after  issuance  of  the  transfer  letter.  It  will  be  prepared 
in  an  acceptable  format  7  and  in  accordance  with  the  following  instructions: 
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(1)  CPCI  Nomenclature  -  Enter  the  approved  nomenclature  of  the  CPCI. 

(2)  Release  Number-  Enter  the  new  release  number  of  the  OFP  to  be  released. 

(3)  Transfer  Letter  Date  -  Enter  the  date  of  the  transfer  letter  for  this  OFP. 

(4)  Modification  Request  Number  -  Enter  the  numbers  os  all  MRs  which  have  been 
resolved  since  the  last  issuance  of  this  section.  MRs  will  remain  on  this  report 
for  one  issue  before  being  removed. 

(5)  Impacted  Program  or  Document  -  Enter  the  number  of  the  software  element  or 
document  against  which  the  MR  is  written. 

(6)  Remarks  -  Enter  a  few  words  description  of  the  MR. 

(7)  MR  Number  -  Enter  the  numbers  of  all  MRs  written  against  this  CPCI  but 

not  yet  resolved  at  the  date  of  this  index  issue. 

(8)  Class  Change  -  Enter  the  class  of  change  specified  on  the  MR. 

(9)  Date  Issued  -  Enter  the  date  that  the  HR  was  issued. 

(10)  Date  Due  -  Enter  the  date  solution  is  due  for  Class  B  MRs. 

(11)  Remarks  -  Enter  a  few  words  description  of  the  MR. 

f.  Change  Status  Listing  (Computer  Program)  -  Section  I  -  This  report  will  be 
prepared  in  an  acceptable  format  and  in  accordance  with  the  following  instructions: 

(1)  System  -  Enter  the  title  and  number  of  the  system  of  which  the  CPCI  is  a  part. 

(2)  Date  -  Enter  the  preparation  date  of  this  section. 

(3)  CPCI  Number  and  Nomenclature  -  Enter  the  number  and  name  of  the  CPCI  as  it 

appears  on  the  front  of  the  CPCI  development  specification. 

(4)  Change  Number  -  Enter  the  numbers  of  all  change  reports,  deficiency  reports 
and  engineering  change  proposals  written  against  the  reference  CPCI.  The  entry  will 
appear  in  each  subsequent  issue  for  at  least  one  issue  following  either  (a)  disapproval 
of  the  change  or  (b)  completion  of  implementation  of  the  change. 

(5)  Title  -  Enter  the  short  title  of  the  change. 

(6)  Status  -  Enter  one  of  the  status  indications  listed  as  follows: 

(a)  S  -  Change  not  yet  considered  by  the  review  board. 

(b)  C  -  Initial  approval  by  the  review  board. 

(c)  D  -  Disapproval  by  the  review  board. 

(d)  X  -  Deferred  by  the  review  board. 

(e)  A  -  Approved  by  the  appropriate  review  boa  d  for  inclusion  in  a  change 

block. 

(f)  I  -  Implemented. 
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g.  Change  Status  Listing  -  Section  II  -  This  section  of  the  listing  will  consist 
of  one  form  for  each  change  listed  in  Section  I  with  a  status  of  C,  D,  X,  A  or  I. 

They  will  be  prepared  in  an  acceptable  format  and  in  accordance  with  the  following 
instructions : 

(1)  Change  Number  -  Enter  change  number  as  enter  in  Section  I. 

(2)  Enter  the  date  that  the  change  report  was  prepared. 

(3)  Change  Title  -  Enter  'the  short  title  of  the  change  report. 

(4)  Summary  of  Problem  -  Enter  a  brief  summary  of  the  problem  which  the  change 
proposes  to  resolve. 

(5)  Description  of  Proposed  Solution  -  Enter  a  brief  description  of  the 
proposed  solution. 

(6)  Reference  Documents  -  Enter  a  listing  of  letters,  reports  of  design 
studies  or  tests,  problem  reports,  etc.  relative  to  this  change. 

(7)  Action  Status  -  Enter  a  statement  as  to  whether  the  change  report  has 
been  approved  or  disapproved  by  the  review  board,  has  been  returned  or  withdrawn  for 
revision/correction,  has  been  implemented,  etc., 

(8)  Implementation  Status  -  Enter  the  scheduled  date  of  distribution 
of  the  new  CPCI  version. 
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1.  SCOPE.  These  pages  list  the  configuration  reviews  and  topics  to  be  covered 
in  support  of  operational  flight  program  changes, 

a.  The  conference  and  reviews,  except  those  at  a  contractor  facility,  are 
to  be  scheduled  by  configuration  management  personnel. 

b.  Minutes  prepared  by  configuration  management  personnel  and  signed  by 
representatives  of  configuration  management;  OFP  design;  and  validation  and 
verification,  constitutes  satisfactory  completion  of  a  review. 

2.  OFP  TECHNICAL  CONFERENCE.  An  informal  presentation  and  discussion  of  proposed 
changes  and  system  engineering  studies  addressing  the  following  topics  as  a 
minimum: 

a.  Mission  and  program  requirements  analysis. 

b.  Preliminary  requirements  allocation, 

c.  Trade  Studies. 

d.  System  interface  studies. 

e.  Test  planning. 

f.  Effect  on  facility  CIs. 

g.  Effect  on  integrated  logistics  support, 

h.  Functional  flow  analysis. 

i.  Human  Factors  Analysis. 

j.  System  safety  analysis. 

3.  INITIAL  DESIGN  REVIEW.  The  following  topics,  as  a  minimum,  should  be 
addressed: 

a.  Ensure  that  the  final  system  specification  adequately  satisfies  mission 
requirements. 

b.  Ensure  that  technical  risks  are  identified  and  reduced  through  trade-off. 


c.  Ensure  compatibility  of  CPCI  design  approach  with  system  requirements 
and  with  other  system  equipment  and  facilities  or  other  software  programs. 

d.  Review  the  system  specification  and  preliminary  development  specification 
changes  for  format,  content,  technical  adequacy  and  completion. 
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e.  Identify  all  computer  program  CIs  required  throughout  the  change  cycle, 
(e.g..  Operational  programs,  maintenance/diagnostic  programs,  test/debug  programs, 
exercise  and  analysis  programs,  simulation  programs  and  other  required  support 
programs. ) 

f.  Identify  modifications  required  to  the  support/test  hardware/software. 

g.  Review  adequacy  of  the  development  test  plans. 

h.  Review  the  system  functional  flow  that  identifies  allocation  of  computer 
program  components  and  depicts  the  sequence  of  operation. 

i.  Review  detail  storage  allocation. 

j.  Review  structure  and  organization  of  data  bases. 

k.  Review  critical  timing  requirements. 

l.  Review  CPCI  interaction  with  personnel  subsystem  requirements. 

m.  Identify  the  interfaces  between  CPCI  and  hardware  CIs  sufficiently  to 
enable  computer  program  design  to  proceed  independently. 

n.  Identify  OFP  aspects  sensitive  to  system  safety. 

4.  DETAIL  DESIGN  REVIEW.  The  following  topics,  as  a  minimum,  should  be 
addressed: 

a.  Ensure  compatibility  of  detail  design  with  the  development  specification. 

b.  Review  updated  sizing  and  timing  data. 

c.  Review  all  interface  requirements  for  compatibility  with  system  design, 
by  analysis  of  detailed  flow  charts  and  other  descriptive  documentation,  and 
ensure  that  the  requirements  are  complete.  Review  the  formats  of  all  inputs 
and  outputs.  Review  the  parameters  which  may  occur  in  each  of  the  formats  and 
identify  the  valid  values,  or  range  of  values,  and  address  techniques  for 
recovering  from  invalid  parameter  values.  The  review  will  address  the  interface 
between  CPCIs,  between  CPCs  within  each  CPCI,  and  between  CPCIs  and  equipment  CIs. 

d.  Ensure  design  integrity  by  review  of  logic  diagrams,  storage  allocation 
charts,  detailed  flow  charts,  etc.,  which  are  a  part  of  the  product  specification. 

e.  Review  interaction  with  data  bases. 


f.  Review  updating  changes  to  the  system  and  development  specifications 
subsequent  to  the  Initial  Design  Review  and  ensure  that  changes  are  reflected 
in  preliminary  product  specifications. 

g.  Review  plans  for  supporting  the  CPCIs  including  the  modifications  required 
of  the  support/test  hardware/software  and  support  documentation. 
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h.  Review  development  and  validation  test  plans  for  currency  and  technical 
adequacy  in  compliance  with  the  development  specification. 

i.  Review  preliminary  changes  to  user's  technical  and  computer  programming 
manuals  for  technical  adequacy. 

5.  VALIDATION  TEST  REVIEW.  The  following  topics,  as  a  minimum,  should  be 
addressed: 

a.  Review  validation  test  data  to  ensure  the  CPCIs  performance  is  in 
compliance  with  the  development  specification.  A  discussion  will  include 
requirements  of  the  development  specification  not  met  in  validation  testing 
and  a  proposed  solution  to  each  discrepancy. 

b.  Review  the  Initial  Design  Review  and  Detail  Design  Review  minutes  to 
ensure  that  all  findings  have  been  incorporated  and  completed. 

c.  Review  the  product  specification  change  for  format  and  completeness. 

d.  Review  changes  to  the  user's  and  computer  programming  manuals  for 
format  and  completeness. 

e.  Review  flight  test  procedures  for  technical  adequacy. 

6.  ACCEPTANCE  TEST  REVIEW.  The  following  topics,  as  a  minimum,  should  be 
addressed: 

a.  Review  flight  test  results  and  user  comments.  Determine  disposition 
of  user  comments. 

b.  Review  Validation  Test  Review  Minutes  for  recorded  discrepancies 
that  require  action.  Ensure  that  necessary  action  has  been  taken. 

c.  Review  the  product  specification,  including  its  flow  charts,  listings, 
design  narratives,  data  base  characteristics,  storage  allocation  charts,  and 
timing  and  sequencing  characteristics,  to  ensure  that  it  adequately  defines 
the  CPCI. 

d.  Review  final  changes  to  the  user's  and  computer  programming  manuals 
for  format,  completeness  and  technical  adequacy. 

e.  Review  the  Technical  Report  for  completeness  and  technical  adequacy. 

f.  Review  the  Version  Description  Document  to  ensure  that  it  accurately 
depicts  the  system  to  be  released. 
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7,  QUALIFICATION  TEST  REVIEW.  The  following  topics,  as  a  minimum,  should  be 
addressed: 

a.  Review  test  data  to  ensure  that  CPCIs  performance  is  in  compliance  with 
the  development  specification.  A  discussion  will  include  requirements  of  the 
development  specification  not  met  in  testing  and  a  proposed  solution  to  each 
discrepancy. 

b.  Review  the  Initial  Design  Review  and  Detail  Design  Review  minutes 
to  ensure  that  all  findings  have  been  incorporated. 

c.  Review  the  product  specification  change  for  format  and  completeness, 
including  its  flow  charts,  listings,  design  narratives,  data  base  character¬ 
istics,  storage  allocation  charts,  and  timing  and  sequencing  characteristics, 
to  ensure  that  it  adequately  defines  the  CPCI. 

d.  Review  changes  to  the  user's  and  computer  programming  manuals  for 
format,  completeness  and  technical  adequacy. 

e.  Review  the  Technical  Report  for  completeness  and  technical  adequacy. 

f.  Review  the  Version  Description  Document  to  ensure  that  it  accurately 
depicts  the  system  to  be  released. 
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MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES  (Cont) _ DATE: 

STRUCTURED  DESIGN?  -  DESCRIBE 

NO 

STRUCTURED  PROGRAMMING?  -  DESCRIBE 

NO 

CODING  GUIDELINES: 

Programming  standards  are  being  developed 

CHANGE  ENTRY  METHODS: 

On-Line  Terminal 


SCHEDULE: 

15  month  block  change  cycle 


REPORTING: 

See  pages  F-18  through  F-24 


COMMENTS: 
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DOCUMENTATION:  See  pages  F-31  through F-34 

REQUIREMENTS: 

DESIGN: 

USER: 


PROGRAM  PROBLEM  REPORTING  SYSTEM: 

MDR/UER  or  Informal  requests 

Problems  are  reported  via  the  standard  MIPS  G026  system.  Informal  request 
and  MPRs/UERs  are  sometimes  used. 


COMMENTS: 
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1.  SCOPE.  These  pages  describe  the  format  and/or  contents  of  documentation 
required  during  modification  of  operational  flight  programs.  (Documentation 
is  not  necessarily  limited  to  this  list.) 

2.  SYSTEM  SPECIFICATION.  Changes  to  this  specification  affecting  OFPs  will 
be  made  by  OFP  design  personnel.  It  states  the  technical  and  mission  require¬ 
ments  for  a  system  as  an  entity,  allocates  requirements  to  functional  areas 
and  defines  the  interfaces  between  or  among  the  functional  areas.  Use  MIL- 
STD-483,  Appendix  III,  as  a  guide  in  preparation  of  this  specification. 

3.  DEVELOPMENT  SPECIFICATION.  This  specification,  one  for  each  computer 
program  configuration  item,  to  be  maintained  by  OFP  design  personnel,  describes 
in  operational;  function;  and  mathematical  language,  all  of  the  requirements 
necessary  to  design  and  verify  the  required  computer  program  in  terms  of 
performance  criteria.  The  specification  provides  the  logical,  detailed 
description  of  performance  requirements  of  a  computer  program.  It  provides 
the  tests  required  to  assure  development  of  a  computer  program  satisfactory 
for  the  intended  use.  Use  MIL-STD-490,  Appendix  VI,  as  a  guide  in  preparation 
of  this  specification. 

4.  PRODUCT  SPECIFICATION.  This  specification,  one  for  each  computer  program 
configuration  item,  to  be  maintained  by  OFP  design  personnel,  specifies  the 
detailed  design  configuration  in  terms  of  technical  descriptions  and  flow 
charts,  and  includes  complete  listings  of  source  code  instructions.  Use  MIL- 
STD-490,  Appendix  XIII,  as  a  guide  in  preparation  of  this  specification. 

5.  DEVELOPMENT  TEST  PLANS.  These  plans,  to  be  prepared  by  OFP  design  per¬ 
sonnel,  specify  the  test  objective,  elements  or  modules  to  be  tested,  method 
of  testing  and  acceptance  criteria. 

6.  VALIDATION  TEST  PLANS.  These  plans,  to  be  prepared  by  validation  and 
verification  personnel,  specify  the  method  and  content  for  each  test  required 
to  validate  the  CPCI  and  lower  level  performance  requirements  contained  in  the 
applicable  development  specification.  It  will  define  the  test  requirements, 
test  conditions,  test  equipment,  support  software,  and  criteria  for  acceptance. 
Test  plans  will  be  derived  from  test  requirements  of  the  applicable  development 
specification. 

7.  DEVELOPMENT  REPORT.  This  report,  to  be  prepared  by  OFP  design  personnel, 
will  include  the  change  number,  with  brief  title,  of  all  changes  included  in 
the  block  change.  Include  reference  to  any  emergency  changes  which  were 
merged  with  the  block  change.  Indicate  any  changes  which  were  added  or 
deleted  since  CPCS3/CC3  approval  of  the  change  block.  Present  a  brief  summary 
of  any  feasibility  study  of  included  changes.  Briefly  describe  any  problems 
which  were  encountered  in  the  design.  Present  a  statement  to  the  fact  that 
the  Software  System  Safety  Checklist  has  been  completed  during  analysis  and 
design. 
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8.  DEVELOPMENT  TEST  PROCEDURES.  This  document,  to  be  prepared  by  OFP  design 
personnel,  will  specify  step-by-step  procedures  for  implementing  the  test 
definitions  of  the  applicable  test  plans.  It  will  include  procedures  for 
exercising  the  code,  proving  logic  accuracy,  testing  limits,  verifying 
timing,  and  so  on.  It  will  include  detailed  acceptance  criteria. 

9.  VALIDATION  TEST  PROCEDURES .  This  document,  to  be  prepared  by  validation 
and  verification  personnel,  will  specify  the  step-by-step  procedures  for 
implementing  the  test  definitions  of  the  applicable  validation  test  plans. 

It  will  specify  details  concerning  test  setup,  operation,  evaluation,  etc.. 
Procedures  will  be  derived  from  the  applicable  test  plans  and  development 
specification. 

10.  FLIGHT  TEST  PLANS.  These  plans,  to  be  prepared  by  validation  and 
verification  personnel,  will  specify  the  method  and  contents  for  each  test 
required  to  validate  the  total  integrated  system  under  flight  conditions.  It 
will  define  the  test  requirements,  test  conditions  and  general  criteria  for 
acceptance.  Test  plans  will  be  derived  from  the  applicable  development 
specifications. 

11.  FLIGHT  TEST  PROCEDURES.  This  document,  to  be  prepared  by  validation  and 
verification  personnel,  will  specify  the  step-by-step  procedures  for 
implementing  the  test  definitions  of  the  flight  test  plans.  It  will  specify 
details  concerning  test  setup,  operation,  evaluation,  etc.. 

12.  TRANSFER  LETTER.  This  letter,  from  the  OFP  Design  Section  to  the  Validation 
and  Verification  Section,  will  identify  the  OFP  baseline  and  addendum,  when 
applicable,  which  is  to  be  validated.  It  will  give  the  date  of  release  for 
validation  testing.  The  letter  will  include  a  listing  of  all  known  problems 
where  the  software  deviated  from  the  requirements  of  the  development  specification, 
with  a  discussion  of  the  problem  and  proposed  solution.  It  is  also  to  include 

a  listing  of  all  outstanding  modification  requests. 

13.  TECHNICAL  REPORTS.  This  report  to  be  prepared  by  validation  and  verifica¬ 
tion  personnel,  will  be  a  final  test  report  for  each  OFP  being  changed  and  will 
include  the  following  items  as  a  minimum: 

a.  Identification  of  test  objectives,  including  applicable  requirements, 
specification  title,  number  and  date,  as  appropriate. 

b.  Nare  and  CPIN  of  OFP  being  tested. 

c.  Summary  of  test  results  stating  what  tests  were  performed  and  the 
results  of  each  test. 

d.  Description  of  test  facility,  including  any  control  conditions  imposed 
during  the  test. 

e.  Discussion  of  test  result  analyses  and  conclusions. 

f.  Statement  to  the  fact  that  the  Software  System  Safety  Checklist 
has  been  completed  during  validation  and  verification. 

14.  VERSION  DESCRIPTION  DOCUMENT.  This  document,  to  be  prepared  by  OFP  design 
personnel,  will  specify  the  exact  program  configuration  released  to  the  user. 

a.  Title  Page  -  The  title  page  will  be  prepared  in  an  approved  format 
and  in  accordance  with  the  following  instructions.  , 
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(1)  CPCI  Nomenclature  -  Enter  the  name  of  the  CPCI  as  it  appears  on  the 
Front  cover  of  the  CPCI  product  specification. 

(2)  CPIN  -  Enter  the  CPIN  of  the  OFP. 

(3)  Version  Number  -  Enter  the  version  number  of  the  OFP  being  released. 

(4)  Version  Issue  Date  -  Enter  the  date  that  the  Version  Description 
Document  (VDD)  was  first  issued. 


(5)  System  -  Enter  the  title  of  the  system  of  which  the  CPCI  is  a 


part . 


(6)  CPCI  Product  Specification  Number  -  Enter  the  number  of  the  CPCI 
product  specification. 

(7)  VDD  Revision  Letter  -  For  a  change  to  an  existing  version  (interim 
VDD)  only,  enter  the  revision  letter  to  the  version.  (e.g.,  "A"  represents 

the  first  interim  change  to  a  computer  program.) 

(8)  VDD  Revision  Date  -  For  a  change  to  an  existing  version  (interim 
VDD)  only,  enter  the  date  that  the  revised  VDD  is  being  issued. 

(9)  ECP/Change  Package  Designator  -  Enter  the  ECP  number  or  the 
internally  generated  block  change  designator. 

(10)  Signature  -  Signature  and  typed  name  of  the  OFP  design  section 
supervisor . 

(11)  Signature  -  Signature  and  typed  name  of  the  validation  and 
verification  supervisor. 

(12)  Signature  -  Signature  and  typed  name  of  the  configuration 
management  representative. 

b.  Content  Page  -  The  contents  of  the  document  will  be  in  accordance  with 
the  following  instructions: 

(1)  Inventory  of  Materials  Released  -  List  the  description,  format  and 
contents  of  all  items  (tape,  cards,  discs)  which  are  covered  by  a  CPCI  number. 
Identify  all  utility  and/or  support  computer  program  release  documents  which 
are  not  a  part  of  the  released  items  but  which  are  required  to  operate,  load 

or  regenerate  the  released  CPCI. 

(2)  Inventory  of  CPCI  Contents  -  Identify  all  computer  programs  and 
data  content,  either  by  reference  to  appropriate  specifications  and  manuals 
and/or  by  listing,  which  are  being  released. 

(.3)  Class  II  Changes  Installed  -  List  the  change  number  and  date  of 
all  Class  II  changes  to  the  computer  programs  and  data  base  incorporated  since 
the  previous  version/revision. 
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(4)  Class  I  Changes  Installed  -  List  the  change  number  and  date  of  all 
Class  I  changes  to  the  computer  programs  and  data  base  incorporated  since  the 
previous  version/revision. 

(5)  Adaptation  Data  -  Identify,  by  reference  to  appropriate  specification 
and/or  listings,  all  unique-to-site  data  which  are  contained  in  the  items  being 
released.  This  section  shall  also  identify  changes  which  have  been  made  to 

the  adaptation  data  as  a  result  of  the  change. 

(6)  Interface  Compatibility  -  Indicate  other  systems  and/or  CIs  affected 
by  the  changes  incorporated  in  this  new  release. 

(7)  Bibliography  of  Reference  Documents  -  List  the  title  and  date  of 
all  pertinent  documents  related  to  the  release  of  a  new  version. 

(8)  Operational  Description  -  For  each  Class  II  and  Class  I  change 
listed  in  this  version/revision,  prepare  a  subsection  containing  the  operational 
effect  of  the  change. 

(9)  Installation  Instructions  -  Describe,  directly  or  by  reference, 

the  method  to  be  used  to  install  and  checkout  the  delivered  CPCI  version/revision. 


(10)  Possible  Problems  and  Known  Errors  -  Identify  aspects  of  the  change 
which  should  be  further  tested.  Identify  and  possible  problems  or  known  errors 
and  describe  any  steps  being  taken  to  resolve  the  problems  or  correct  the  errors. 
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DESCRIPTION  OF  SKILL  LEVEL  AND  TYPE  (AF/CS/CONT)  OF  PERSONNEL  MAINTAINING  THIS  PACKAGE 

POSITION  DESCRIPTION 
FOR 

ELECTRONICS  ENGINEER,  GS-855-12 

INTRODUCTION :  The  purpose  of  the  position  is  to  serve  as  a  Computer  Software 
project  engineer  in  support  of  Operational  Flight  Programs  (OFP)  and  associated 
support  software  as  assigned. 

DUTIES  AND  RESPONSIBILITIES: 

1.  Accomplishes  complex  engineering  projects  for  which  existing  guidelines  are 
not,  in  most  cases,  available.  Such  projects  include  those  affecting  maintainability 
and  reliability  of  Warner  Robins  ALC  prime  avionic  systems.  Develops  software  design: 
such  as  prototypes  for  AF  wide  adaptation.  Assigned  engineering  projects  are  of  such 
a  nature  that  the  incumbent  is  required  to  work  in  areas  where  precedent  data, 
criteria,  methods,  or  techniques  are  inadequate,  are  controversial,  or  contain 
critical  gaps. 

2.  Has  responsibility  for  maintaining  the  design  and  performance  integrity  of 
assigned  systems.  Deficiencies  present  in  system  software  are  inherently  complex 
and  incongruous  in  nature.  Resolution  of  service,  field,  and  system  revealed 
software  deficiencies  require  that  the  incumbent  plan,  research  and  design  modifica¬ 
tions  having  far  reaching  consequences  in  the  aircraft  mission.  Due  to  the 
complexity  of  the  computer  controlled  avionic  systems,  the  problems  may  be  large 

in  scope,  affecting  both  complex  and  conventional  portions.  Conventional  portions 
may  be  assigned  to  lower  grade  engineers,  but  incumbent  must  maintain  the  reponsibil.it 
for  evaluation  and  incorporation  into  the  overall  solution. 

3.  Incumhent  must  be  proficient  in  the  programming  of  computers  at  the  machine 
and/or  assembly  language  level,  as  well  as  use  of  higher  level  languages,  and  be 
responsible  for  the  design  and  redesign  of  subprograms,  codes,  flowcharts,  and  de¬ 
bugging  of  program  changes.  Due  to  the  complex  interface  between  the  software  and 
hardware  of  computer  controlled  avionic  systems,  this  programming  is  accomplished 
utilizing  knowledge  of  hardware  operations  and  limitations  created  by  hardware 
design.  Works  closely  with  hardware  oriented  systems/project  engineer  to  ensure  a 
unified  solution  to  problems  is  accomplished  in  the  most  effective  manner. 

4.  Incumbent  partiepates  in  the  operational  testing  of  avionic  software  by 
setting  up  computer  runs  to  check  programs  against  environmental  and  operational 
simulations.  Detects  and  identifies  program  troubles  to  such  a  degree  that  he  is 
able  to  direct  the  finding  of  subtle  programming  errors  which  will  cause  minor  or 
major  program  malfunctions,  or  improper  indications  of  faults. 

5.  Accomplishes  engineering  and  analytical  tasks  for  isolating  system  defi¬ 
ciencies  and  develops  modifications  to  correct  these.  The  incumbent  performs  en¬ 
gineering/analytical  studies  and  procedures  to  determine  causes.  Conducts 
analyses  to  define  or  assess  system  requirements.  Develops  system  specifications 
and  concepts.  Develops  system  interface  designs  and  develops  associated  technical 
computer  software  programs.  Prepares  laboratory,  ground  and  flight  test  plans. 
Maintains  liaison  with  operational  units  and  provides  consultation  to  those  units 
on  problems  or  questions  which  arise. 
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6.  Scope  of  personal  contacts  is  broad  as  the  incumbent  consults  with  1M, 

SM,  Procurement,  Shop  Contractor,  and  operating  command  personnel.  Decisions 
on  technical  aspects  of  assigned  systems  must  be  rendered  independently  without 
benefit  of  review  during  periods  of  TDY. 

7.  Designs  modifications  and  improvements  to  highly  complex  technical  mission 
oriented  avionics  systems  programs. 

8.  Prepares  inputs  (tasks),  provides  guidance,  monitors,  evaluates  and  approves 
results  of  contractor  efforts  on  Service  Engineering  contracts. 


9  Performs  other  related  duties  as  required. 

CONTROLS  OVER  WORK;  Works  under  general  supervision  of  the  Section  Chief  who  gives 
assignments  in  terms  of  broad  general  objectives  and  relative  priority.  Little  or 
no  technical  guidance  is  received,  but  controversial  policy  is  jointly  resolved. 

Work  is  reviewed  for  adequacy  in  terms  of  broad  policy  objectives  and  policy  compli¬ 
ance.  Efficiency  is  determined  by  end  results. 

OTHER  SIGNIFICANT  FACTS! 


1.  Position  requires  that  incumbent  participates  in  flight  test  as  assigned. 

2.  Incumbent  is  subject  to  TDY  in  CONUS  or  overseas  for  periods  up  to  several 
weeks . 

3.  Specialized  training  may  necessitate  PCS  for  up  to  one  year  at  contractor’s 
plant  at  the  discretion  of  management. 

4.  Military  aircraft  will  be  used,  when  available,  to  perform  TPY.  Commercial 
aircraft  or  other  modes  of  transportation  will  be  used  when  military  aircraft  is  not 
available. 

5.  Fields  of  engineering:  Electronic  -  55%;  Electrical  -  5%;  Computer  Science 
-  40%. 

6.  Specializations  in  the  electronic  and  digital  systems  engineering  fields  are: 
logic  circuitry,  program  development  and  testing,  logic  design,  signal  integration 
networks,  micro-electronics,  large  and  medium  scale  integrated  logical  and  memory 
circuits,  computer  technology,  programming  languages,  simulation  modelling,  integra¬ 
tion  of  computer  controlled  airborne  equipment,  and  software  documentation  and 
configuration  control. 

7.  Subject  to  call  during  off  duty  hours  and  an  occasional  requirement  for 
weekend  and  holiday  work. 
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BUILDINGS: 

F-15 space  requirements  are  projected  as  follows: 


Ci.  rrent 

1983 

1986 

AISF  Equip' t. 

4800* 

9000 

11000 

Office 

5000 

7000 

7000 

Support 

500 

2700 

3000 

10,300 

18,700 

21,000 

2 

*Numbers  are  Ft . 
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Computer  Facilities  (Type,  Quantity,  Application,  Cost  &  Usage) 

General  -  The  AISF  will  be  composed  of  a  Dynamic  Simulation  System  (DSS) ,  a 
data  Reduction  and  Analysis  System  (DRAS),  A  Flight  Test  Preprocessing  System  (FTPS) 
and  support  areas.  Its  purpose  is  to  provide  AFLC  with  a  facility  to:  (a)  design 
and  develop  software  changes  to  the  CC  and  RDP  -  primarily  by  utilizing  the  basic 
debug  and  static  test  capability  of  the  DSS;  (b)  verify  and  validate  software  changt 
to  the  CC  and  RDP  software  prior  to  flight  test  -  primarily  by  utilizing  the 
dynamic  test  capability  of  the  DSS;  (c)  flight  test  software  changes  to  the  CC  and 
RDP  -  by  means  of  an  instrumented  F-15  aircraft  and  FTPS;  simulation  analysis, 

OFP  analysis  and  data  reduction  analysis. 

Dynamic  Simulation  Systems  (DDS)  -  The  purpose  of  the  DSS  is  to  perform  hard¬ 
ware,  software,  and  hardware/sof tware  system  and  subsystem  tests  and  integration 
and  will  consist  of  computer  programs,  airborne  computers,  selected  avionics  and 
a  control  processing  system.  The  system  will  provide  basic  debug  and  static  test 
capability  for  the  airborne  computers  and  programs  by  means  of  single  step  command 
driving  functions  or  by  mission  scenario  profiles.  In  addition,  a  dynamic  test 
capability  will  allow  the  airborne  computers,  programs  and  avionics  hardware  to 
be  subjected  to  any  selected  mode  of  aircraft  operation  together  with  a 
number  of  simulated  environmental  stimuli.  The  DSS  will  consist  of  a  complete 
radar  subsystem  control  processing  system  and  selected  avionics,  sensors,  controls, 
and  displays  operating  under  the  control  of  the  control  processing  system  and 
associated  peripherals. 

a.  Control  Processing  System  (CPS)  -  The  CPS  for  the  DSS  will  provide  the 
computation,  control  and  interface  signals  necessary  to  exercise  and  monitor  the 
F-15  avionics  in  real  time,  simulating  aircraft  operation. 

The  minimum  peripheral  equipment  requirements  are: 

Line  Printer 
Card  Reader 

Computer  Graphics  System 
Tape  Controller  and  drives  (4) 

Mini-computer  Interfaces  (for  CC  and  RDP) 

Paper  Tape  Reader /Punch 
Disk  Controller  and  Drive  (5) 

Keyboard  CRT  Displays  (7)  (3  Control  &  4  Terminals) 

Simulation  and  Switching  Unit 
Pr in ter /Plot ter 

b.  F-15  Avionics  Hardware  -  The  DSS  will  maximize  the  use  of  existing  F-15 
avionics  hardware.  Some  avionics  hardware  not  installed  in  the  facility  but 
whose  functions  are  necessary  will  have  those  functions  provided  by  a  simulation 
program  through  a  special  interface. 
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The  avionics  hardware  required  for  the  DSS  are: 


Central  Computer  (CC) 

Head-Up  Display  (HUD) 

Fire  Control  Radar  (FCR) 
Indicator  Group  (IG) 

Armament  Control  Set  (ACS) 
Primary  Flight  Instruments 
Navigation  Control  Panel 
Indicator  Set 

Attitude  Direction  Indicator 
BIT  Control  Panel  (BCP) 


CP-1075/AYK 

AN/AVO-20 

AN/APG-63 

OD-60/A 

AN/AWG-20 

C-8849/ASN-109 
AN/AJN-18 
(ADI)  ARU-39/A 


c.  Cockpit  Mock-Up  (CMU)  -  The  CMU  will  tie  the  various  F-15  avionics  together 
for  operation  in  the  AISF  environment  as  part  of  the  DSS,  and  will  have  the  cock¬ 
pit  instruments  configured  much  like  the  F-15  aircraft. 

d.  Special  Input/Output  and  Excitation  Equipment  -  Special  equipment  will  be 
required  to  replace,  interface,  and/or  simulate  the  F-15  Avionics  equipment. 

(1)  Special  input/output  equipment  will  replace  the  following  avionics  equipment: 

Attitude  Heading  Reference  Set  AN/ASN-108 

Lead  Computing  Gyro  (LCG)  CN/1377/AWG 

Tactical  Electronic  Warface  System  (TEWS)  j 

Automatic  Direction  Finder  (ADF)  OA-8639/ARD 

Tactical  Air  Navigation  (TACAN)  AN/ARN-111 

Inertial  Navigation  System  (INS)  AN/ASN-109 

Instrument  Landing  Set  (1LS)  AN/ARN-112 

I 

(2)  A  special  interface  unit  shall  provide  the  ILS,  ADF,  and  TACAN  navigation 
data  through  the  Flight  Director  Adapter  (FDA),  KX-9119/AHB-18,  for  the  Horizontal 
Situation  Indicator  (HSI),  ID-1805/AJN-18. 


(3)  Othc"  special  interface  units  will  be  required  for  the  flight  control  stick, 
throttle,  BIT  control  panel,  and  cockpit  switches  to  provide  the  appropriate  data 
to  the  CPS  for  simulation  control  and  equipment  status. 


(4)  A  power  control  panel  will  provide  a  central  location  for  circuit  breakers, 
power  monitors,  and  avionics  power  control.  This  unit  will  be  built  into  standard 
panel  racks  and  will  proide  all  electrical  power  required  for  the  avionics  mock- 
up  and  the  special  simulator/stimulator  equipment.  It  will  replace  the  F-15 
generators  and  power  system. 


(5>  A  radar  target  generator  will  simulate  radar  targets  for  the  F-15  radar 
system. 

(6)  An  air  data  computer  (ADC)  simulator  and  interface  will  provide  simulation 
of  the  ADC  functions,  and  interface  with  the  primary  flight  instruments. 
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(7)  A  CC  console  will  monitor,  load,  and  control  the  internal  registers  of 
the  CC  and  will  interface  the  CC  aerospace  ground  equipment  connector  with  the  CPS. 

C8)  A  HUD  target/horizon  flight  profile  simulator  will  provide  the 
simulated  (correlated  with  the  earth  model)  target  image  for  the  pilot.  The  unit 
will  be  mounted  so  that  the  pilot  can  see  the  simulate  I  target/hor izon  and  flight 
profile  with  respect  to  the  HUD  symbology. 

(9)  A  stores  station  simulator  rack  will  simulate  the  functions  of  the  various 
stores  stations  on  the  F-15  aircraft. 

e.  Auxiliary  Equipment  -  An  intercom  system  will  be  installed  in  the  DDS. 

Data  Reduction  and  Analysis  System  (DRAS)  -  The  purpose  of  the  DRAS  is  to 
provide  the  capability  of  flight  test  data  reduction  and  analysis,  data  management, 
and  assembling  OFP's.  For  flight  test  data  reduction  and  analysis,  the  system 
requires  CC,  RDP  and  TEWS  computer  compatible  digital  tapes  which  have  been  pre- 
processed  by  scaling,  analysis  techniques  and  output  moding  for  the  computer  tapes. 
In  the  data  management  configuration  the  DRAS  operates  as  an  information  retrieval 
system  for  the  DDS,  the  OFP's  flight  test,  reports  and  studies.  As  an  assembler 
the  DRAS  will  convert  the  CC  and  RDP  assembly  language  programs  to  machine  code 
and  produce  a  master  mylar  tape  for  each  OFP.  The  DRAS  will  consist  of  a  control 
processor  and  peripherals. 

a.  Control  Processor  -  The  DRAS  control  processor  will  provide  the  computa¬ 
tions,  controls,  and  interface  to  perform  flight  test  data  reduction  and  analysis, 
data  management,  and  OFP  assembling. 

b.  Control  Processor  Peripherals  -  The  minimum  peripheral  equipment  require¬ 
ments  are: 

Disk  Storage  Units  (2) 

Magnetic  Tape  Drives  (2) 

Keyboard  CRT  Display  (7)  (1  Control,  6  Terminals) 

Card  Reader  (900  CPM) 

Line  Printer  (600  LPM) 

Paper  Tape  Punch/Rader 
Printer  Plotter 
Tape  Punches  (10) 

Flight  Test  Preprocessing  System  (FTPS)  -  The  FTPS  will  have  the  capability 
to  perform  preliminary  screening  or  quick-look  evaluation  of  the  F-15  flight  test 
data,  to  pre-process  the  data  for  processing  by  the  DRAS,  and  to  present  the  DRAS 
processed  data  in  hardcopy  graph  and  tabular  form.  Facilities  will  also  be 
included  to  view  the  video  recordings  of  the  HUD,  VSD,  and  TEWS  cockpit  visual 
presentation.  Input  media  will  be  compatible  with  the  flight  test  data  recording 
media  and  DSS  media.  Output  media  is  to  be  compatible  with  DSS  media.  Flight 
data  will  be  gathered  by  a  production  configured  F-15  assigned  to  WR-ALC/KM.  The 
FTPS  will  consist  of  a  PCM  front  end,  a  control  processor  and  associated  peripheral: 
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a.  Control  Processor  -  The  FTPS  control  processor  will  provide  the 
computations,  control,  and  interface  to  preprocess  the  F-15  flight  test  data. 
Features  of  the  control  processor  include  direct  memory  address  (DMA),  high  speed 
hardware  floating  point  arithmetic,  priority  interrupts,  and  operator  interrupts. 

b.  Control  Processor  Peripherals  —  The  minimum  peripheral  equipment 
requirements  are: 

Disk  Storage  Units 
Magnetic  Tape  Drive  (2) 

Card  Reader  (600  CPM) 

Teletype 

Keyboard  CRT  Display 

Pulse  Code  Modulation  (PCM)  Interface 

Airborne  Recording  Device  Compatible  Input  Equipment 

Quick  Look  Presentations 

c.  Auxiliary  Equipment  -  The  FTPS  will  also  include  facilities  to  view  the 
video  recordings  of  the  HUD,  BSD,  and  TEWS  visual  representation.  To  enable  this 
function,  the  auxiliary  equipment  should  include  a  video  tape  playback  machine, 

a  video  de-multiplexer  facility  and  two  (2)  cathode  ray  tube  display  stations. 
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General  -  Computer  software  will  be  provided  for  both  simulation  and  support 
of  the  DSS,  DRAS  and  FTPS. 

DSS  Software  -  The  DSS  software  will  simulate  the  F-15  aircraft  dynamics, 
environment,  and  missing  avionics  equipment  so  the  software  in  the  CC  and  RDP  can 
be  exercised  throughout  their  full  range  of  operation.  The  primary  function  of 
the  DSS  software  is  to  permit  F-15  OFP  validation  and  verification  (V&V)  in  a 
dynamically  simulated  environment.  It  will  contain  modular  structured  source  code 
consisting  of  the  executive  module,  sensor  models,  environment  models,  F-15 
airframe  models  and  subystem  models.  Standard  FORTRAN  IV  language  will  be 
utilized  as  the  main  programming  language,  and  assembly  language  used  only  when  time 
considerations,  CRT  control,  or  communications  with  the  real  time  operating 
systems  (RTOS)  require  its  use.  The  design  of  the  DSS  software  will  be  such  that 
the  entire  range  t>f  the  CC  and  RDP  can  be  exercised  with  or  without  a  man-in-the- 
loop.  When  the  man  is  taken  out  of  the  loop,  the  cockpit  portion  of  the  interaction 
will  be  simulated  so  that  the  operator  can  have  complete  control  of  the  input/output 
signals.  This  will  be  accomplished  through  either  a  scenario  mission  tape  or  a 
simulated  pilot  model.  The  organization  of  the  software  will  be  designed  to  keep 
the  simulation  within  a  real  time  environment,  and  to  allow  for  non-real  time, 
step-by-step  operation  through  operator  control  of  key  CRT  formatted  messages.  An 
RTOS  will  interact  with  the  executive  module  so  that  control  of  the  simulation  can 
be  transferred  to  the  operator  after  his  CRT  entry. 

DRAS  Software  -  Standard  support  and  utility  software  for  the  DRAS  will  be 
provided.  These  support  packages  will  be  those  usually  supplied  by  the  processor 
vendors.  Special  support  software  for  the  DRAS  shall  be  provided  such  as  file 
management,  interactive  operation,  etc.  General  support  software  is  needed  to 
permit  offline  data  analysis  and  will  include  batch  processing  monitor,  time 
sharing  monitor,  FORTRAN  processor,  symbol,  meta-symbol,  data  management  system, 
sort/merge,  report  writer,  editor,  simulation  package,  circuit  analysis  package, 
and  plotter  package. 

FTPS  Software  -  The  FTPS  Software  will  provide  the  capability  for  quick  look 
evaluation  of  flight  test  data,  for  preprocessing  flight  test  data  so  that  it  is 
compatible  with  the  DRAS,  and  for  printing  and  plotting  DRAS  reduced  data. 

General  Support  Software  -  Software  will  be  supplied  to:  provide  tools  which 
aid  in  the  design,  development,  and  debugging  of  software;  generate  listings  of 
data,  histograms  and  time  history  plots;  provide  tools  which  aid  in  configuration 
management  of  the  AISF  hardware  and  software;  provide  for  the  transfer  of  data  from 
one  recording  media  to  another. 

Subsystem  Test  Area  -  As  part  of  the  LRU  Analysis  Center  and  the  F-15  AISF, 
applicable  subsystem  test  equipment  will  be  made  available  to  WR-ALC/MMF.  as  they 
are  phased  out  of  the  F-15  developmental  effort.  This  equipment  is  the  hot-bench 
type  subsystem  test  station  in  use  to  test  out  applicable  LRU's.  This  equipment 
will  be  made  available  to  WR-ALC  as  the  development  cycle  comes  to  an  end. 
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SOFTWARE  PACKAGE  CHARACTERISTICS  -  TRAINING  REQUIREMENTS 
PROGRAMMER  TRAINING: 


15  Feb.’ 80 


The  F-15  weapon,  system’s  reliance  on  a  highly  integrated  state-of-the-art 
avionics  system  requires  responsible  personnel  to  be  knowledgeable  of  the  system 
in  order  to  maintain  the  software.  The  training  required  to  acquire  this 
knowledge  will  be  sectioned  into  formal  course  work  and  informal  hands-on  training. 

The  formal  courses  submitted  to  ATC  training  are  outlined  below.  These 
courses  will  supply  the  basic  knowledge  required  to  support  the  OFPs. 


MMEKF-3 


MMECD-14 


Length  (weeks) 


FORTRAN  IV 

Avionics  System 

Simulation  Techniques 

Central  Computer  OFP  Design 

Central  Computer  AP-1  Assembly  Language 

RDP  OFP  Design 

RDP  Assembly  Language 

Special  Equipment  (Software) 

APG-63  Radar  Familiarization 


Specialized  CC  Avionics  Training  (J 

Specialized  Radar  Avionics  Training 

Harris  Slash  7  Assembler /VMS  JCL  Programming 

Adage  GP-440  Graphics  Peripheral  and 
Microcode  Programming 

Kalman  Filter  -  Theory  and  Application 
APG-63  RTBS  Operation  and  Maintenance 
Analog-Digital  Techniques  and  Application 
Data  Reduction/Analysis  Techniques  I 


3  (10  is 
,  desirable) 


(incorporated  into  MMEKF-6) 
(incorporated  into  iImECD-14 


2  (8  is  desirable) 


PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  - 
FLIGHT  TEST  REQUIREMENTS 


DATE: 


15  Feb.' 80 


These  will  be  one  fully  instrumented  F-15  dedicated  to  the  flight  test  program. 

It  is  expected  to  fly  about  100  hrs/year  in  support  of  all  changes  (S/W,  H/W, 
Tactical  Electronics  Warfare  System,  etc.)  Approximately  15  flights  (1  hr/flight) 
are  expected  for  each  software  block,  change. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


SOFTWARE  PACKAGE  MAINTENANCE  COST  HISTORY 

YEARLY  COST  OF  MAINTAINING  PACKAGE: 


No  cost  data  were  available. 


DATE: 


15  Feb. 


'80 


PREDICTIVE  SOFTWARE  COST  MODEL 


HISTORICAL  DATA  SOURCES 

Data  Base  Name: 
Location: 

Contact  Person: 

Phone  Number: 

General  Contents: 


Period  Covered: 


_ OATE:  15  F‘b-'8° 

F-15  OFP 

WR-ALC/MMEC,  Robbins  AFB,  GA. 

Charles  Singleton 
(912)  926-2753 
N/A 


They  hope  to  complete  the  first  central  computer  OFP  change 
by  the  end  of  1980.  ] 


Data  Quality: 


N/A 


detailed  data 


PREDICTIVE  SOFTWARE  COST  MODEL 
FIELD  EVALUATION  REPORT 


GENERAL  SOFTWARE  PACKAGE  DESCRIPTION 


DATE:  31  JAN  80 


ALC:  tfR 


SOFTWARE  PACKAGE:  N/A 


PERSONNEL  CONTACTED: 

Boby  McDonald  (912)  926-2204/5780 
Major  A1  Becker  (912)  926-2607 


SOFTWARE  PACKAGE  CHARACTERISTICS: 
SIZE:  N/A 

LANGUAGE: 

APPLICATION 

COMPLEXITY: 

YEAR  DEVELOPED: 

DEVELOPER: 

COMMENTS 


WEAPON  SYSTEM: 


EW  SOFTWARE 


HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS: 
MANUFACTURER:  N/A 


MODEL  NUM0ER/OESIGNATOR: 


WORD  SIZE: 


MEMORY  SIZE: 


MEMORY  FILL: 


WEAPON  SYSTEM  USE:  N/A 


NUMBER  OF  USERS: 


LOCATIONS  Of  USERS: 


FREQUENCY  OF  USE: 


INTERVIEWER(S):  r.  r.  Walna,  G.  L.  Foreman 


PRECEDING  PAOK  BU«WW*  raw 


PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  PERSONNEL 

ALC:  WR 

KEY  PERSONNEL/OGRANIZATION: 


OFFICE  SYMBOL: 


MMR 


MMR  (EW  Management) 

MMRD  (Regts.  and  Distr.)- 
MMRM  (logs  Mgt.) 

MMRD  (Prod.  Mgt.) 

MMRR  (Engr.  and  Rel.) 


LTC  L.  Huffman 
J .  Dunnaway 
E.  Eass 
W.  Smith 
J.  Brittain 


a iTE- .  SUM  a 


TOTAL  ASSIGNED  PERSONNEL  (NUMBER  &  TYPE): 

MMRR  has  223  filled  positions  versus  283  authorized.  Requirements  for  FY80 
are  318. 


TOTAL  PACKAGES  MAINTAINED  (NUMBER  &  TYPE): 


See  page  G-4. 


PREDICTIVE  SOFTWARE  COST  MODEL 

MAINTENANCE  AGENCY  -  WORK  DISTRIBUTION  _ DATE:  3i  jan  80 

DESCRIPTION  OF  WORK  PACKAGE  DISTRIBUTION,  INCLUDING  RESPONSIBILITIES  AND  DEGREE  OF 
SPECIALIZATION  OF  AF/CS/CONTR  PERSONNEL 

MMRR  is  organized  as  shown  below.  FY80  manpower  requirements  by  system 
are  shown  on  page  G-4. 

MMRRC  -  Jammers 

MMRRV  -  Receivers 

MMRRI  -  Integrated  Systems 

MMRRA  -  Threat  simulation  to  test  systems 

MMRRS  -  Technical  Data,  spares  definition,  user  interface,  deficiency  reports 
MMRRW  -  Administration,  budget,  configuration  control 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


System  Total  Personnel  Requirement  (INCL.O/H) 


ALQ-131* 

30.7 

ALQ-165(ASPJ) 

4.1 

ALQ-155* 

16.2 

ESAS*W 

6.3 

ALQ-117 

5.3 

ALQ-119 

27.6 

APR-38* 

34.6 

ALQ-125* 

7.2 

ALR-56* 

18.8 

ALQ-135* 

11.5 

ALE-45 

4.0 

IRS 

7.3 

USM-464(FLTS) 

16.4 

ALQ-99 

16.4 

ARC 

8.6 

ALR-46* 

39.6 

ALR-62* 

20.8 

ALQ-153 

5.7 

ALR-69* 

36.7 

317.8 

*Sof tware-controlled  systems 
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MAINTENANCE  AGENCY  -  COST  ACCOUNTING  SYSTEM _ DATE:  n  ,TA 

MMRR  has  had  an  engineering  project  log  on-line  since  July  1978.  All  data 
is  stored  on  a  drum  except  for  closed-out  projects.  Data  categories  include 

System 

Project  #  (i.e.,  specific  task) 

Work  Unit  Code 
Engineer 
Estimated  Hours 
Actual  Hours 
Open  Date 
Due  Date 
Close  Date 
Task  Description 


L 


PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES _ DATE:  31  JAN  80 

SUPPORT  PHILOSOPHY: 

EW  software  changes  are  supported  under  a  block  change  concept 
(see  page  G-7)  except  for  urgent  or  emergency  changes.  Those 
are  processed  upon  receipt  on  a  "crash"  basis. 


CHANGE  CONTROL  METHODS: 

FORMAL  OR  INFORMAL:  Formal 

CHANGE  REVIEW  PROCESS:  See  pages  G-8  through  G-18. 


CONFIGURATION  IDENTIFICATION  METHODS:  See  page  G-15. 

CONFIGURATION  CHANGE  CONTROL  METHODS:  See  pages  G-8  through  G-18. 

CONFIGURATION  STATUS  ACCOUNTING  METHODS:  See  page  G-13. 

SOFTWARE  LIBRARY  CONTROL  PROCEDURES:  System-dependent 


PREDICTIVE  SOFTWARE  COST  MOO  EL 


CONTINUATION  SHEET 


DATE:  31  JAN  80 


MMR  OPERATING  INSTRUCTION  800-01 


*».  CONFIGURATION  CONTROL  PROCEDURES 


CONFIGURATION  MANAGEMENT  CONTROL  OVER  SOFTWARE  CHANGES  IS  IMPOSED 
VIA  The  screening  panel,  and/or  the  CPCSB  IN  ACCORDANCE  WITH  THIS 
REGULATION,  no  SOFTWARE  CHANGE  REQUEST,  REDESIGN  OF  EXISTING 
COMPUTER  PROGRAMS  OR  CHANGE  TO  THE  SPECIFICATIONS  THAT  DESCRIBE 
the  program  configuration  can  be  accomplished  without  the 
concurrence  of  these  bodies,  management  control  is  exercised  at 
formal  CONFIGURATION  reviews  and  audits. 


H , 1 ,  REVIEWS 


A  configuration  management  review  is  a  meeting 

CONFIGURATION  MANAGEMENT  BOOT  (CPCSB,  SP,  CCB, 
THE  PURPOSE  OF  APPROVING,  DISAPPROVING  OR  CERT 


OF  A  DESIGNATED 
ETC.l  CONVENED  FOR 
FYING  BASELINE 


DOCUMENTATION  and  changes  to  approved  baseline  DOCUMENTATION, 
REVIEWS  DEFINED  FOR  THE  Ew  SYSTEM  SOFTWARE  CHANGE  PROCESS  ARE} 


,  SYSTEM  REQUIREMENT  REVIEW  ( SRR ) 

•  COMBINED  SYSTEM  DESIGN  REVIEW  AND 
PRELIMINARY  0ES1GN  REVIEW  ( SDR/PDR ) 

,  CRITICAL  OESIGN  REVIEW  ( COR  ) 

,  PROOuCT  VERIFICATION  REVIEW  IPVRI 

•  FORMAL  (SYSTEM)  QUALIFICATION  REVIEW 
(FQR) 


R  « I • 1 •  SRR 


IN  THE  SRR,  The  CPCSB  PROVIDES  THE  AUTHORIZATION  TO  PROCEED  WITH 
BLOCK  CYCLE  SOFTWARE  CHANGES  AND  COMMITTMENT  OF  MMRR  RESOURCES, 

THE  CPCSB  APPROVES  THE  FOLLOWING! 

.  THE  ANALYSIS  OF  THE  FEASIBILITY  OF  THE 
PROPOSED  CHANGES 

,  PROPOSED  CHANGES  (PRELIMINARY  SCNS)  TO  THE 
SYSTEM  SPECIFICATION  (FUNCTIONAL  BASELINE) 

•  IMPLEMENTION  PLAN 
,  ATE  SOFTWARE  CHANGES 

ALSO  THE  CPCSB  WILL  ASCERTAIN  THAT  MIPS  HAVE  BEEN  OPENED,  AND 
REVIEW  AND  INITIAL  THE  PROCESS  CONTROL  DOCUMENTS  (MDR/SPR 
CHECKLIST,  CHANGE  PROCESS  CHECK  LIST,  CHANGE  REQUEST  INDEX,  MORS 
AND  MIPS),  THE  SRR  IS  NOT  HELD  FOR  EMERGENCY  OR  URGENT  CHANGES  AS 
THE  APPROVAL  TO  PROCEED  WITH  A  PRIORITY  CHANGE  IS  AUTOMATICALLY 


448 


rsrsm: 


mu  rnmmm 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET _ OATE:  31  JAN  80 


GRANTED  (ASSUMING  THE  CHANGE  IS  FEASIBLE)  UNDER  EMERGENCY  OR 
URGENT  CONDITIONS* 


H  .  1 . 2  ,  SDR/POR 


IN  THE  COMBINED  SYSTEM  DESIGN  REVIEW  ANO  PRELIMINARY  DESIGN 
REVIE*,  THE  SYSTEM  SPECIFICATION,  THE  SOFTWARE  PART  I 
SPECIFICATION  CHANGES,  TEST  PLANS  AND  THE  SOFTWARE  DESIGN  APPROACH 
(INCLUDING  ALLOCATIONS  OF  SOFTWARE  SUBSYSTEM  FUNCTIONS)  wILk  BE 
REVIEWED  BY  The  screening  panel  tSP)*  the  approved  part  I 
SPECIFICATION  CONSTITUTES  THE  SOFTWARE  ALLOCATED  BASELINE* 


R.1.3.  CDR 


IN  THE  CRITICAL  DESIGN  REVIEW,  THE  PRELIMINARY  PART  II 
specification  design  CHANGES  AND  DETAILED  coding  DIAGRAMS  WILL  BE 
REVIEwEO  BY  THE  LEAO  ENGINEER.  THE  PURPOSE  WILL  BE  TO  ASSURE  THAT 
the  programmer* s  approach  to  coding  is  sound. 


N.I.N.  PVR 


BY  THE  PRODUCT  VERIFICATION  REVIEW  (HELD  AT  THE  COMPLETION  OF  THE 
DESIGN  PHASE),  C0DE0  AND  TESTED  CHANGES  WILL  BE  DOCUMENTED  AS 
CHANGES  TO  THE  SOFTWARE  PART  II  SPECIFICATION.  THE  SOFTWARE 
SYSTEM  TEST  RESULTS  AND  PART  II  SPECIFICATION  WILL  BE  REVIEWED  BY 
THE  SCREENING  PANEL  (SP).  THE  APPROVED  PART  II  SPECIFICATION 
CONSTITUTES  THE  PRELIMINARY  PRODUCT  BASELINE. 


R.I.S.  FkR 


IN  THE  FORMAL  QUALIFICATION  REVIEW,  THE  CPCSB  WILL  REVIEW  THE 
REPORTS  OF  THE  FUNCTIONAL  CONFIGURATION  AUDIT  ( FC A )  AND  PHYSICAL 
CONFIGURATION  AUOlT  (PCA),  AND  WILL  APPROVE  OR  DISAPPROVE  THE 
CHANGE  PACKAGE  FOR  DISTRIBUTION,  THE  DOCUMENTS  THAT  ARE  APPROVED 
AT  THE  FQR  CONSTITUTE  THE  SYSTEM  PRODUCT  BASELINE. 


<t.2*  AUDITS 


TWO  FORMAL  AUDITS,  THE  FUNCTIONAL  CONFIGURATION  AUDIT  ( F C A  )  AND 

the  physical  configuration  audit  < pc a >  are  the  primary  means  for 
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CONTINUATION  SHEET _  _ DATE:  31  JAN  80 


QUALITY  CONTROL  Of  THE  PRODUCT  OF  THE  CHANGE  PROCESS. 


R.2.I.  FUNCTIONAL  CONFIGURATION  AUDIT  ( FC A  ) 


THE  FCA  VERIFYS  THAT  THE  CPCI  HAS  ACHIEVED  THE  PERFORMANCE 
SPECIFIED  IN  THE  PART  I  AND  SYSTEMS  SPECIFICATIONS.  THE 
REPORTS/RESULTS  OF  THE  VARIOUS  TESTS  ISW  SIMULATION,  ISS  SYSTEM, 

ewols/ecsas,  etc.)  above  the  code  segment/mooule  level  are 

AUDITED  FOR  RESULTS  VERSUS  REQUIREMENTS.  REVIEWED  ARE! 

•  are  the  requirements  appropriately 
testedt 

.  ARE  The  RESULTS  ACCEPTABLE  (I.E.  DID  THE 
CPCI  hEET  THE  REQUIREMENTS!* 

THE  APPROPRIATE  SECTIONS  OF  THE  CHANGE  PROCESS  CHECK  LIST,  SIGNED 
OFF,  TEST  RESULTS  SYNOPSIS  AND  THE  FCA  REPORT  DOCUMENT  THE  KCA. 


R.2.2.  PHYSICAL  CONFIGURATION  AUDIT  ( PC A  > 


THE  PURPOSE  OF  THE  PCA  IS  TO  ESTABLISH  THE  ACCURACY  ANO 
COMPLETENESS  OF  THE  DOCUMENTATION  THAT  DESCRIBES  THE  CONFIGURATION 
ITEM  AFTER  ALL  CHANGES  HAVE  BEEN  INCORPORATED,  THE  PCA  INCLUDES  A 
COMP AR I S I  ON  OF  THE  PART  II  SPECIFICATION  CHANGES  *ITH  THOSE  OF  THE 
FLOW  CHARTS*  COMPUTER  PROGRAM  LISTINGS,  MANUALS/HANBBOOKS ,  TEST 
PLANS/REPORTS  AND  CHANGE  PROCESS  DOCUMENTATION.  A  FINAL  CHECK  IS 
TO  COMPARE  A  LISTING  GENERATED  BY  THE  CPCI  AT  THE  PCA  WITH  THE 
LISTING  (REDLINED  OR  GENERATED  OURING  the  CHANGE  PROCESS)  IN  THE 
PART  II  SPECIFICATION, 

THE  APPROPRIATE  SIGNEO  OFF  SECTIONS  OF  THE  CHANGE  PROCESS 
CHECKLIST  And  the  PCA  report  satisfy  the  requirements  for  PCA 
documentation. 


1.3.  TOOLS  OF  CONFIGURATION  MANAGEMENT 


THE  TOOLS  AVA 
CONFIGURATION 


.COMPUTER 


•baseline 


r 


LA8LE  TO  THE  SCREENING  PANEL  ANO  CPCSB  TO  PERFORM 

management  are: 

PROGRAM  IDENTIFICATION  NUMBER  (CPIN) 

DOCUMENTATION 
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CONTINUATION  SHEET 


DATE:  31  JAN  80 


•  CHANGE  CONTROL  CHECK  LISTS,  FORMS  AND  REPORTS 
.STATUS  ACCOUNTING 


M.3.1.  CP  I N 


THE  CP  1 N  SYSTEM,  DESCRIBED  JN  AFR  800-1H  AND  MMRO I  800-02  <CN 
CPINS),  PROVIDES  THE  VEHICLE  FOR  IDENTIFICATION  OF  COMPUTER 
PROGRAMS  IAND  VARIOUS  V ER S 1 ONS / R E V  I S I ONS  )  IN  THE  FIELD. 


R.3.2.  BASELINE  DOCUMENTATION 

THROUGHOUT  THE  50F  TWARE  CHANGE  CYCLE,  THE  BASELINE  MANAGEMENT 
CONCEPT  PERMITS  A  BASIS  FOR  CONTROLLING  THE  CHANGE  PROCESS.  THE 
FOLLOWING  ARE  THE  REQUIRED  DOCUMENTS  FOR  SYSTEM  AnD  SOFTWARE 
CONFIGURATION  IDENTIFICATION,  CHANGE  CONTROL  AND  STATUS 
ACCOUNTING  ARE  BASED  ON  THESE  DOCUMENTS. 

.  SYSTEM  SPECIFICATION  (FUNCTIONAL  BASELINE  I 

.  DEVELOPMENT  (PART  I)  SPECIFICATION  (ALLOCATED 
BASELINE  ) 

.  PRODUCT  (PART  III  SPECIFICATION  (PRODUCT  BASELINE) 

.  TEST  PLANS/PROCEDURES 

.  TEST  REPORTS 

R.3.3,  CHANGE  CONTROL  CHECK  LISTS,  FORMS  AND  REPORTS 


CONFIGURATION  CONTROL  IS  EXERTED  THROUGH  THE  IMPLEMENTATION  OF  THE 
BELOW  LISTED  FORMS,  REPORTS,  AND  CHECK  LISTS; 

t.  Change  process  checklist;  a  procedural  checklist  for  block 

CPCI  CHANGES,  TO  MONITOR  THAT  THE  CORRECT  PROCEDURES  HAVE  BEEN 
ACCOMPLISHED  BEFORE  PROCEEDING  TO  THE  NEXT  STEP  IN  THE  SOFTWARE 
CHANGE  PROCESS  ( MMRR  FORM), 

2.  software  problem  report  ispri:  an  af  form  1775  used  to 

DOCUMENT  A  SOFTWARE  DEFICIENCY  ENCOUNTERED  DURING  TESTING  OF  EW 
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CONTINUATION  SHEET _ PATE:  31  JAN  80 


OFP,  ate,  or  associated  support  software,  the  action  in  the  spr 
hust  be  approved  before  it  is  implemented, 

3*  change  request  index:  a  listing  of  change  requests  denoting 
CONTROL  NUMBERS,  PROBLEM  DESCRIPTIONS,  AND  WORK  EFFORT, 

H •  MOR/SPR  CHECKLIST:  a  PROCESSING  LIST  GENERATED  FOR  EACH 

mdr/spr.  this  form  provides  the  results  of  the  feasibility  study 

BY  THE  SCREENING  PANEL, 

s,  material  improvement  project  < m i p i  aflc  form  rb:  used  to 
record  a  project  requirement  .for  the  removal  of  a  deficiency. 

6.  iss  test  plans/procedures: 

•  module/integration:  test  CASES  I  INPUT/OUTPUT )  for  each 
MODULE  AND  A  MODULE  INTEGRATION  PROCEDURE. 

•  software  simulation:  test  CASES  I  INPUT/OUTPUT )  for  the 
INTEGRATED  SOFTWARE  PROGRAM, 

•  ISS  SYSTEM  TESTS!  TEST  CASES  (INPUT/OUTPUT)  USING 
STIMULATION  of  the  system  hot  mockup  by  rf  GENERATORS, 

7,  ISS  TEST  reports:  documentation  of  the  results  of  tests 
performed  according  to  the  iss  test  plans/procedures  document, 

a,  system  verification  test  plans/procedures j  documentation  of 

THE  TEST  OBJECTIVES,  CRITERIA,  CASES,  METHOD  OF  TESTING,  AND  OTHER 
PERTINENT  DATA  NEEDED  TO  CONDUCT  TESTING  FOR  THE  FOLLOWING  TEST 

systems: 

•  EwOLS/ECS AS 

•  DEES 

•  AFEwS 

•  flight  test 

?.  SYSTEM  VERIFICATION  TEST  REPORTS!  DOCUMENTATION  OF  THE 
RESULTS  OF  THE  TESTS  CONDUCTED  IN  ACCORDANCE  WITH  THE  SYSTEM 
VERIFICATION  TEST  PLANS/PROCEDURES. 

10.  AFLC  FORM  751  THE  »CPCSB  ITEM  RECORD*  WHICH  CONTAINS  A 
DESCRIPTION  OF  THE  SYSTEM  CHANGE  AND  THE  CPCSB  APPROVAL  OR 
DISAPPROVAL. 

11.  AFLC  FORM  873!  *  T 1  ME  COMPLIANCE  TECH  OROER  REQUIREMENTS' 

REQUIRED  TO  SET  TCTO  NUMBER,  DATA  CODE,  ISSUE  DATE,  ANO  RESCISSION 
DATE, 

12.  AFLC  FORM  505!  CPIN/AF  CRJ  DATA  AND  CONTROL  RECORD  -  PART  I 
(CPIN  REQUEST  FORM)  FOR  NEW  OR  REVISED  NUMBERS,  PART  I* 
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DATE:  31  JAN  80 


13.  AFLC  FORM  &Q6I  CPIN/AF  CRJ  DATA  AND  CONTROL  RECORD  PART  II 
ICPIN  REQUEST  FORM )  FOR  NEW  OR  REVISED  NUMBERS.  PART  II. 

1H.  AFLC  FORM  2S2I  ’PUBLICATION  CHANGE  REQUEST  FORM'*  THIS 
FORM  IS  USED  TO  ACCOMPLISH  AN  ACTUAL  CHANGE  TO  AN  E|ISTING 

technical  order. 

15.  AFLC  FORM  875i  'TCT0  CHECKLIST'*  THIS  FORM  INSURES  JHAT 
ALL  ITEMS  PERTINENT  TO  THE  MODIFICATION  PROCESS  ARE  ACCOMPLISHED. 

1*.  SCNS  SPECIFICATION  CHANGE  NOTICE  FORM  DD  1696  TRACKS  MDR 
NUMBER  AND  INDICATES  THE  BASELINE  SPECIFICATION  PAGES  CHANGED  AS  A 
RESULT  OF  CHANGES  IMPLEMENTED  TO  CORRECT  THE  DEFICIENCY.  OWE  IS 
ISSUED  FOR  EACH  SPECIFICATION  CHANGED. 

17.  DCNI  DOCUMENT  CHANGE  NOTICE  IS  USED  SIMILAR  TO  THE  SCN  but 
FOR  DOCUMENTS  (TEST  PLANS/PROCEDURES,  MANUALS,  ETC.)  OTHER  THAN 

specifications. 

18.  COMPUTER  PROGRAM  CLASS  II  CHANGE  REPORT;  DESCRIBES  THE  CLASS 
II  CHANGE.  AS  A  RULE,  CLASS  II  CHANGES  ARE  INCLUDED  IN  SCNS, 

issued  to  incorporate  class  i  changes. 

19.  WR-ALC  form  3091  CONFIGURATION  MANAGEMENT  SYSTEM-INPUT  DATA. 

20.  EMERGENCY/URGENT  change  process  checklist;  an  abbreviated 
CHANGE  LIST  FORM  USED  ONLY  FOR  EMERGENCY  OR  URGENT  CHANGES. 


R.3.M.  STATUS  ACCOUNTING 


CONFIGURATION  STATUS  ACCOUNTING  IS  DEFINED  IN  MIL-STD-HBO  AS  S 
'THE  RECORDING  AND  REPORTING  OF  THE  INFORMATION  THAT  IS  NEEDED  TO 
MANAGE  CONFIGURATION  EFFECTIVELY,  INCLUDING  A  LISTING  OF  THE 
APPROVED  CONFIGURATION  IDENTIFICATION,  THE  STATUS  OF  PROPOSED 
CHANGES  TO  CONFIGURATIONS,  ANO  THE  IMPLEMENTATION  STATUS  OF 
APPROVED  CHANGES.'  the  PURPOSE  IS  TO  provide  MANAGEMENT; 

.  AN  OVERVIEW  OF  PROGRESS  OF  CHANGE  IMPLEMENTATION  (PROGRAM, 
TESTS,  ANO  DOCUMENTATION). 

•  timely  INFORMATION  ABOUT  PROBLEMS  ENCOUNTERED  OR 
ANTICIPATED, 

•  A  BASIS  FOR  STANDARDIZING  AND  IMPROVING  REPORTING 
PROCEDURES.  A  DECISION  TO  MAKE  A  CHANGE  MUST  BE  IMPLEMENTED  AND 
RECORDS  ARE  NEEDED  ON  How  THE  SYSTEM  CHANGE  IS  EVOLVING.  THESE 
CHANGE  RECOROS  CONSTITUTE  CONF I GURAT I  ON  STATUS  ACCOUNTING.  THEY 
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PROVIDE  THE  MEANS  BY  WHICH  THE  HISTORY  OF  THE  SOFTWARE  SYSTEM  LIFE 
CYCLE  CAN  BE  TRACED. 

SOFTWARE  CONFISCATION  STATUS  ACCOUNTING  USES  THE  SAME  FORMS. 
REPORTS.  AND  CHECKLISTS  AS  CONFIGURATION  CONTROL  (SEE  ABOVE 9  FOR 
RECORDING  AND  REPORTING  THE  following; 

.  the  date  at  which  each  approved 
baseline  came  into  being. 

.  DESCRIPTIVE  INFORMATION  ABOUT  EACH  SOFTWARE  CONFIGURATION 
ITEM.  SUCH  AS  ISSUING  AGENCY.  NOMENCLATURE.  CPIN,  Ew 
SYSTEM,  ETC. 

.  spr/scn  status  idate  written,  approved, 

DISAPPROVED,  IMPLEMENTED). 

.  DESCRIPTIVE  INFORMATION  ABOUT  EACH  CHANGE  REQUEST 
(MDR/SPR  I  . 

.  STATUS  OF  TECHNICAL  AND  ADMINISTRATIVE 

DOCUMENTATION  ASSOCIATED  WITH  A  BASELINE  OR  CPCI 
CHANGE  (SUCH  AS  A  PLAN  PRESCRIBING  TESTS  TO  BE  PERFQRMED 
ON  CPCl  CHANGES), 

•  DEFICIENCIES  IN  A  TO-BE-ESTABLISHED  BASELINE 

(CPCI)  UNCOVERED  OURING  THE  CHANGE  PROCESS  (SPRS). 


*♦.<(.  BLOCK  CHANGE  CYCLE 


THE  BLOCK  CHANGE  CYCLE  WILL  BE  THE  PRIMARY  MANAGEMENT  METHOD  FOR 
SCHEDULING,  DEVELOPING,  TESTING,  AND  IMPLEMENTING  ROUTINE  CHANGES 
(INCLUDING  CLASS  II  CHANGES)  TO  EW  OFPS,  ATE  AND  RELATED 
OPERATIONAL  SUPPORT  SOFTWARE.  A  COLLECTION  OF  PROGRAM  CHANGES 
WILL  BE  PROCESSED  CONCURRENTLY  IN  EACH  CHANGE  CYCLE  AND  INTEGRATED 
INTO  THE  LATEST  CONFIGURATION  FOR  THE  CPCIS  AFFECTED  FOR  EACH 
SYSTEM.  CHANGE  REQUESTS  WILL  BE  PROCESSED  AND  PLACED  IN  A  QUEUE 
UP  TO  THE  BLOCK  CYCLE  CUTOFF  DATE.  PROGRAM  CHANGES  RECEIVED  AFTER 
THE  CUTOFF  OATE  WILL  BE  REVIEWED  AND  HELD  FOR  THE  NEXT  BLOCK 
CHANGE  CYCLE.  CHANGES  TO  ATE  SOFTWARE  SHALL  BE  COORDINATED  DURING 
THE  SAME  BLOCK  CYCLE  THAT  THE  Ew  OFP  CHANGES  ARE  IMPLEMENTED.  THE 
LENGTH  of  THE  BLOCK  CHANGE  cycle  cutoff  submission  date  and  other 
SIGNIFICANT  MILESTONES  ARE  DECIOED  ON  A  SYSTEM  BY  SYSTEM  BASIS  AND 
ESTABLISHED  IN  THE  SYSTEM  0/S  CMP.  SEE  FIGURE  l  FOR  AN 
ILLUSTRATION  OF  A  HYPOTHETICAL  BLOCK  CYCLE. 

EACH  APPROVED  EMERGENCY  ANO  URGENT  CHANGE  MAY  INTERRUPT  THE  BLOCK 
CYCLE  CHANGE  PROCESS.  THE  E/U  MDR  WILL  BE  FORWARDED  IMMEDIATELY 
TO  THE  SYSTEM  ENGINEERING  GROUP  FOR  IMPLEMENTATION  AND  RELEASE. 
UPON  RELEASE  IT  WILL  BECOME  THE  NEW  BASELINE  FOR  the  interrupted 
CHANGE  CYCLE,  THE  BASELINE  DOCUMENTS  WILL  THEN  REPRESENT  A  NEW 
VERSION  CPCI  THAT  IS  DIFFERENT  FROM  THE  ORIGINAL  CPCI 
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CONFIGURATION  OF  THE  INTERRUPTED  BLOCK  CYCLE.  THEREFORE,  THE 

interrupted  seock  cycle  may  be  required  to  return  to  its  initial 
starting  POINT  AND  ALL  CHANGES  made  up  to  THE  TIME  OF  INTERRUPTION 
may  have  to  BE  REEXAMINEO, 


change  cycle  identification 


EACH  BLOCK  change  CYCLE  SHALL  BE  IDENTIFIED  FOR  EACH  SYSTEM  BY  THE 
SYSTEM  NOMECLATURE  AND  A  CONSECUTIVE  BLOCK  NUMBER  0 1  , 02 , 03 , *---  N 
(I.E.  ALR-RA  BLOCK  -Oil,  EMERGENCY  OR  URGENT  CHANGES  WILL  UTILIZE 
THE  MUR  NUMBER  AS  THE  IDENTIFIER.  PERFORMANCE  OF  BLOCK  CYCLE 
CHANGES  MAY  BE  INTERRUPTED  ONLY  FOR  E  OR  U  PRIORITIZED  CHANGES. 
ROUTINE  CHANGES  THAT  ARE  NOT  COMPLETED  DUE  TO  THE  DIVERSION  TO  E 
OR  U  CHANGE  PRIORITIES  OR  FOR  OTHER  REASONS  WILL  LIKEWISE  BE  HELD 
OVER  TO  THE  NEXT  BLOCK  CYCLE, 


REQUIREMENTS  ANALYSIS 


A  PRELIMINARY  ANALYSIS  OF  EACH  NEW  ROUTINE  PROGRAM  CHANGE  REQUEST 
IS  HELD  AS  EACH  IS  RECEIVED,  THIS  WILL  INCLUDE  UNCOMPLETED 
CHANGES  LEFT  OVER  FROM  THE  PREVIOUS  BLOCK  CYCLE.  DURING  THIS 
ANALYSIS,  THE  SCREENING  PANEL  WILL  IDENTIFY  SYSTEM  REQUIREMENTS, 
ASSESS  FEASIBILITY,  AND  WILL  ESTIMATE  IMPACT,  COSTS,  RESOURCES, 

AND  LEVELS  OF  EFFORT,  CHANGES  DETERMINED  TO  REQUIRE  CONTRACTOR 
SUPPORT  WILL  BE  IDENTIFIED  FOR  LATER  PRESENTATION  TO  THE  CCB. 
LIKEWISE,  HAROWARE  CHANGES  WILL  BE  DEFINED  *5  EARLY  AS  POSSIBLE  TO 
THE  CCB,  THE  HARDWARE  CHANGE  RESULTING  FROM  A  SOFTWARE  CHANGE  MAY 
NOT  BE  RELEASED  AT  THE  SAME  TIME  AS  THE  SOFTWARE  CHANGE  BUT  A 
COORDINATED  SCHEDULE  FOR  THE  INSTALLATION  OF  BOTH  SHALL  BE 
ESTABLISHED,  REQUESTS  ONLY  FOR  A  FEASIBILITY  STUDY  WILL  BE 
CONDUCTED  AND  A  REPORT  PROVIOED  TO  THE  APPROPRIATE  COMMAND  BUT  NO 
CHANGE  WILL  BE  PROCESSED, 

WHEN  the  SUBMISSION  CUTOFF  DATE  IS  REACHED,  THE  LISI  OF  CHANGES  IN 
THE  QUEUE  IS  REVIEWED  ANO  PRIORITIZED  BY  NEGOTIATION  WITH  THE  USER 

command,  included  in  this  list  are  the  mdrs  and  sprs  carried  over 

FROM  THE  PREVIOUS  BLOCK  CYCLE,  THE  PRIORITIZED  CHANGE  LIST  IS 
COMPARED  AGAINST  PROJECTED  AVAILABLE  RESOURCES  AND  THE  FINAL  LIST 
OF  CHANGES  TO  BE  INCORPORATED  IN  THE  BLOCK  CHANGE  IS  LIMITED  TO 
THOSE  RESOURCES.  ANY  CHANGES  THAT  COULD  NOT  BE  INCLUDED  WILL  BE 
HELD  OVER  TO  THE  NEXT  BLOCK  CYCLE  ANO  THE  USER  COMMAND  NOTIFIEO 
ACCORDINGLY,  A  SYSTEM  REQUIREMENT  REVIEW  IS  CONVENSD  AND  CPCSB 
CONCURRENCE  IS  REQUESTED  FCR  BLOCK  CHANGE  CONTENT  AND  RESOURCE 
COMMITMENT. 


M 


R.R.3.  IMPLEMENTATION 


THE  BLOCK  CYCLE  IMPLEMENTATION  IS  STARTED  AFTER  THE  SYSTEMS 
REQUIREMENT  REVIEW  WITH  A  REQUIREMENTS  DEFINITION/ALLOCATION  phase 
WHEN  THE  SCREENING  PANEL  MEETS  TO  ANALYZE  THE  CHANGES  SELECTED  FOR 

the  block  cycle,  during  this  phase  the  preliminary  analysis  of 
each  CHANGE  request  is  refined,  system  engineering  studies  are 
conducted  to  define  performance,  design,  interface,  functional 
requirements,  and  test  plans. 


changes  to  ate  software,  if  any,  are  def 
controlled  under  this  mmroi  in  the  same 
whether  the  ate  system  was  originally  oe 
the  decision  to  OELEGaTe  ate  software  ma 

TEST  ( UUT )  SOFTWARE  CHANGES  TO  OTHER  WR- 
RELEASE  THE  RESPONSIBLE  MMRR  SYSTEM  ENG! 
PERFORMING  their  VERIFICATION  AND  VALIDA 
SOFTWARE  CHANGES.  IN  THIS  INSTANCE,  THE 
SHALL  COMPLY  WITH  ALL  REQUIREMENTS  OF  TH 
APPLIES  TO  CONTRACTOR  SUPPORTED  SOFTWARE 
OR  ATE  PROGRAMS. 


1NED  AT  THIS  TIME  AND  ARE 
MANNER  AS  Ew  OFP  CHANGES, 
VELOPED  By  MMRR  OR  ASD. 
INTENANCE  FOR  UNIT  UNDER 
ALC  DIVISIONS  DOES  NOT 
NEERING  UNIT  FROM 
TION  FUNCTION  FOR  ATE 

system  engineering  unit 
IS  MMROI.  THE  Same 

CHANGES,  WHETHER  FOR  Ew 


*».*»,  design  and  test 


the  software  change  activity  includes  design,  coding  check  out, 
testing  and  integration. 

THE  DESIGN  of  THE  CHANGE  CONSISTS  OF  DEFINING,  IN  A  LOGICAL  AND 
ORGANIZED  MANNER,  THE  NECESSARY  FUNCTIONS  AND  OPERATIONS  TO 

satisfy  the  software  requirement,  it  is  during  this  phase  that 

TEST  PLANS  are  GENERATED  TO  ENSURE  A  SATISFACTORY  DEMONSTRATION  OF 
QUALITY  ASSURANCE  REQUIREMENTS. 

IN  THE  CODING  AND  CHECKOUT  PHASE,  THE  DETAILED  SOFTWARE  DESIGN  IS 
TRANSLATED  INTO  A  HIGHER  ORDER  OR  ASSEMBLY  LANGUAGE.  THE  FORMAL 
TEST  PROCEDURES  SHOULD  BE  PREPARED  DURING  THIS  PERIOD. 

THE  TESTING  PHASE  DETERMINES  THAT  THE  SOFTWARE  PERFORMS  AS 
INTENDED  AND  THAT  SYSTEM  REQUIREMENTS  ARE  SATISFIED.  INTEGRATION 
TESTS  UNCLUDING  ISS  LEVEL  TESTS!  SYSTEM  VERIFICATION  TESTS,  AND 
FLIGHT  TESTS  ARE  PERFORMED  USING  INTEGRATED  SYSTEM  COMPONENTS, 
HARDWARE  AS  WELL  AS  SOFTWARE, 
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*».i.  ate  software 


SYSTEM  ENG I NEER I NG  (MMRR)  IS  THE  DESIGNATED  UUT  ATE  SOFTWARE  AND 
INTERFACE  ADAPTER  MANAGER  IN  ACCORDANCE  WITH  AFR  BOfl-lN  vOL  Hi 
AFLC  SUPPLEMENT  NO  1.  AND  THE  'WR-ALC  O/SCMP  FOR  UUT  ATE 

software.*  the  design  ano  test  of  ate  software  changes  will 

NORMALLY  BE  PERFORMED  BY  MMECT  AS  TASKED  BY  MMRR  IN  ACCORDANCE 
WITH  PROCEDURES  OUTLINED  IN  PARAGRAPHS  9.2*2  AND  9.2.3  OF  THE 
ABOVE  MENTIONED  O/SCHP,  THE  SP  ATE  ENGINEER  WILL  PROVIDE  GUIDANCE 
FOR  THIS  PROCEDURE.  IN  SOME  INSTANCES.  AGREEMENTS  WILL  BE  MADE 
BETWEEN  MMRR  AND  MMEC  FOR  MMRR  TO  0R6ANICALLY  SUPPORT  ATE  SOFTWARE 
CHANGES.  IN  ANY  EVENT.  CONFIGURATION  MANAGEMENT  OF  ALL  ATE 
CHANGES  REMAINS  THE  RESPONSIBILITY  OF  MMRR  IRRESPECTIVE  OF  THE 
DESIGN  AGENCY.  THE  ATE  CHANGE  WILL  BE  PROCESSED  IN  ACCORDANCE 
WITH  THIS  MmROI  UP  UNTIL  THE  DESIGN  PHASE  (AFTER  SDR/PDR).  AT 
THIS  POINT  THE  CHANGE  WILL  BE  DESIGNED  AND  TESTED  BY  THE  DESIGN 
AGENCY.  THE  LEAD  ENGINEER  AND/OR  ATE  ENGINEER  WILL  MONITOR  ATE 
VERIFICATION  TESTING  AND  ASSURE  COMP A  TAB  I L  I  TV  WITH  f HE  UUT. 
thereafter,  the  completed  ate  software  CHANGES  with  the  documents 

LISTED  IN  STEP  10  OF  PARAGRAPH  5.1.  WILL  BE  PRESENTED  TO  THE 

screening  panel  for  the  fca/pca  audit,  therefore,  the  sp  and 

CPCSB  REVIEWS,  AUDITS  AND  APPROVAL  PROCEDURES  STATED  HEREIN  WILL 
BE  FOLLOWED  For  ALL  UUT  ATE  SOFTWARE  CHANGES. 


9.9.5.  BASELINE  MANAGEMENT 


9.9.5. i,  change  documentation 


THE  SOFTWARE  SYSTEM  WHICH  ENTERS  A  BLOCK  CYCLE  SHOULD  BE  FULLY 
BASELINED  (SEE  PARAGRAPH  <(,3.2).  THE  CHANGE  PROCESS  WILL  CONVERT 
THESE  BASELINE  DOCUMENTS  TO  NEW  VERSIONS.  CHANGES  TO  THE  SOFTWARE 
WILL  BE  DOCUMENTED  BY  CHANGES  TO  THESE  BASELINES  AND  IDENTIFIED  BY 
A  SPECIFICATION  CHANGE  NOTICE  (SCN)  DD  FORM  1696.  AN  SCN  WILL  BE 

GENERATED  for  each  changed  specification  at  the  time  a  change  to 
THAT  SPECIFICATION  IS  IDENTIFIED.  THE  SCN  SHALL  LIST  ALL  CHANGES 
(CLASS  1  6  III  TO  THAT  SPECIFICATION  FOR  THE  BLOCK  CYCLE,  CLASS 
II  CHANGES  THAT  00  NOT  IMPACT  SOFTWARE  CONFIGURATION  WILL  BE 
DOCUMENT  ON  A  COMPUTER  PROGRAM  CLASS  II  CHANGE  REPORT.  DOCUMENT 
CHANGE  NOTICES  (OCNS)  WILL  BE  ISSUED  FOR  CHANGES  TO  TEST 
PLANS/PHOCEDURES.  THE  SCNS  AND  OCNS  ARE  KEPT  AS  PART  OF  THE 
CHANGE  PROCESS  RECORD  SET  (BLOCK  CYCLE  NOTEBOOK  4  ANO  FUNCTION  AS 
WORKING  INDEXES  FOR  FUTURE  CHANGES.  IN  ORDER  TO  MAINTAIN 
TRACEABILITY  OF  CHANGES,  THE  DOCUMENTATION  MANAGEMENT  PROCEDURES 
IN  THE  NEAT  SECTION  WILL  BE  FOLLOWED. 
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h.r.s.2.  document  at  i  on  maintenance 


TWO  COPIES  or  THE  SYSTEM  SOFTWARE  BASELINE  DOCUMENTS  SET  WILL  BE 
RESIOENT  AT  WR-ALC.  COPY  NO.  1  WILL  BE  MAINTAINED  BY  THE  MMRR 
LEAO  ENGINEER  WHO  IS  RESPONSIBLE  FOR  THE  SYSTEM  BEING  CHANGED. 
COPY  NO.  2  WILL  BE  FILEO  AND  MAINTAINED  BY  MMRRW.  A  THIRD  COPY 
WILL  BE  STORED  FOR  SAFETY  AT  A  DESIGNATED  SITE, 


COPY  NO.  1  WILL  BE  A  WORKING  DOCUMENT.  DURING  A  BLOCK  CYCLE. 
APPROVED  SOFTWARE  CHANGES  WILL  BE  MADE  TO  COPY  NO.  1  BY  REDlINE, 

handwritten  entries,  a  marginal  notation  will  date  each  entry  and 
identify  the  corresponding  spr/mdr.  prior  to  the  end  of  the 
change  cycle,  the  redlined  changed  pages,  the  scns/dcns,  class  ii 
change  reports,  and  the  change  reouest  index  that  correspond  to 
approved,  implemented  changes  will  be  turned  over  to  mmrrw. 

MMRRW  WILL  HAVE  THE  RED  LINED  PAGES  AND  SCNS  RETYPED.  ONE  SET  OF 
TYPED  CHANGED  PAGES  AN0  SCNS  WILL  BE  FORWARDED  To  THE  LEAD 
ENGINEER  WHO  WILL  INSERT  THEM  INTO  COPY  NO.  I,  REPLACING  THE 
CHANGED  PAGES.  COPY  NO.  1  WILL  THEN  CONSTITUTE  THE  NEW  VERSION 
BASELINE. 

COPY  NO.  2  OF  THE  BASELINE  DOCUMENTS  WILL  BE  KEPT  UNCHANGED  IN  THE 
MMRRW  FILES.  THE  SET  OF  TYPED  CHANGED  PAGES  AND  SCNS,  AND  THE 
REDLINED  PAGES  WILL  BE  FILED  WITH  THE  MMRRW  COPY  NO.  2.  COPY  NO, 

2  WILL  THEN  CONSTITUTE  THE  PRECHANGE  BASELINE  DOCUMENTS  AND 
CHANGES  TO  THE  PRECHANGE  DOCUMENTS.  MMRRw  WILL  ALSO  TYPE  THE 
CHANGE  REQUEST  INDEX, 

THE  BASELINE  FILES  AT  MMRRW  WILL  MAINTAIN  TRACEABILITY  OF  CHANGES 
THROUGH  ALL  SEQUENTIAL  BLOCK  CYCLES.  IN  ADDITION  TO  THE  ORIGINAL 
SET  OF  BASELINE  DOCUMENTS,  EACH  BLOCK  CYCLE  FILE  wlLL  CONTAIN  THE 
CHANGE  RECORDS  GENERATED  IN  THE  CYCLE,  INCLUDING! 

.  MDR/SPRS 
.  5CN/DCNS 

•  REDLINED,  CHANGED  PAGES 

,  COMPUTER  PROGRAM  CLASS  II  CHANGE  REPORTS 
.  CHANGE  PROCESS  CHECKLIST 

•  MOR/SPR  CHECK  LISTS 

•  CHANGE  REQUEST  INDEX 

•  PC A  REPORT 
.  FCA  REPORT 

.  IMPLEMENTATION  PLAN 
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Sys  tem-dependent 


STRUCTURED  PROGRAMMING?  -  DESCRIBE 

System-dependent 


CODING  GUIDELINES: 

Informal:  a  code  walk-through  is  scheduled  prior  to  testing  of  the  change. 


CHANGE  ENTRY  METHODS: 

System-dependent:  most  often  on-line  on  small  computer. 


SCHEDULE: 


Depends  on  urgency  of  change 


REPORTING: 


Via  project  log  system 
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documEntJon  And  forms 


OCT  7? 


*•  RfcF£RtNcE  DOCUMENTS 


ES0-TR-77-25R  ESD  GuIDEbOOK 

AN  AF  6UJ0E  TO  COMPUTER 
PROGRAM  CONFIGURATION  MANAGEMENT 


2.  documentation 


the  content  anO  Format  required  For  th^  system,  part  i  and  part 

COMPUTER  PROGRAM  SPECIFICATIONS  ARE  OUTLINED  In  MiL-STD-m90  AS 
SUPPLEMENTED  BY  MIL-STD-R83  (AIR  FORCE).  THE  NOMENCLATURE  USED 
MIL-STD-R90  FOR  THE  VARIOUS  SPECIFICATIONS  ISS 

MMROI  eOU-Ol/MlL-STD-RSJ  MlL-STD-H’O 

SYSTEM  SYSTEM  -  TYPE  A 

PART  I  DEVELOPMENT  -  TYPE  B 

PART  II  PRODUCT  -  TYPE  C 

mil-std-hvo  further  differentiates  computer  program  specificatj 

AS  SUBTYPES  85  AND  CS.  ESD  GUIDEBOOK  ESD-TK-77-2SM  *  AN  AF  GUID 

to  computer  program  configuration  management^  section  3,  provj 
A  TUTORIAL  ON  THE  REQUIREMENTS  TO  BE  DESCRIBED  IN  THESE 

specifications. 

THE  system  contractor  WILL  USUALLY  provide  the  system 
specification,  part  i  development  specification,  part  II  PRODUC 
specification,  test  plans,  test  procedures,  configuration  index 

CHANGE  STATUS  LIST,  AND  VERSION  DESCRIPTION  OESCRiPTiOn  OOCliMEK 
as  baseline  documentation  at  pmrt,  the  contractor  must  be 

DIRECTED  TO  MAINTAIN  THIS  DOCUMENTATION  IF  THE  CONTRACTOR  WILL 
CONTINUE  TO  SUPPORT  THE  SYSTEM  UNDER  wR-ALC  CONTRACT  aFtER  PMRT 

THE  SYSTEM  ENGINEERING  GROUP  IMMRR)  WILL  BE  RESPONSIBLE  TO  MAN/ 
AND  MONITOR  THE  CONTRACTOR  IMPLEMENTED  CHANGES  TO  THE  BASEL  I NE 
00CUM6NTS  AND  THE  CPCI. 

systems  organically  developed  at  wr-alc  must  develop  the  same 
DOCUMENTATION,  all  ORGANICALLY  supported  SYSTEMS  must  MAINTAP 
THE  DOCUMENTATION  WITHIN  MMRR  IN  ACCORDANCE  WITH  THIS  Of. 
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3.  STATUi  ACC0U 

nT In®  fqRmS 

The  statuS  aCcounTing  forms  required  and  t 

Reference  to  the 

INSTRUCTIONS  FOR 

COMPLETING  the  forms,  aRE 

listed  below; 

FORM 

title 

INSTRUCTIONS 

AFLC  FORM  7s 

cpcsb  item  record 

aFLC  SUP  1  TO  AFR 
8O0-I**,  VOL  II 

AF  FORM  177S 

software  problem  report 

ATTACHED  (MODIFIED) 

00  FORM  l69fc 

SPEC.  CHANGE  NOTICE  (SCN) 

attached  (modified) 

MMR  FORM 

MOR/SPR  CHECK  LIST 

ATTACHED 

MMR  FORM 

CHANGE  PROCESS  CHECK  LIST 

1  CPCL  ) 

ATTACHED 

MMR  FORM 

emer. /urgent  change  process  attached 

CHECK  LIST 

MMR  FORM 

CHANGE  REQUEST  INDEX 

attached 

MMR  FORM 

PC A  REPORT 

attached 

MMR  FORM 

FCA  REPORT 

attached 

MMR  FORM 

DOC.  CHANGE  NOTICE  ( DCN ) 

attached 

MMR  FORM 

COMPUTER  program  CLASS  II 
REPORT 

attached 
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instructions  for  Completing  AF  Form  1775,  Software  Problem  Report  (SPR) 

Taken  from  APR  300-15,  Attachment  8,  16  Jan  78 


*  CONTROL  NUMBER:  Enter  a  unique  control  num¬ 
ber  in  accordance  with  local  configuration  manage¬ 
ment  procedures. 

DATE  SUBMITTED:  Self-explanatory. 

TO:  Enter  the  organization  responsible  for  develop¬ 
ment  or  maintenance  of  the  software. 

*  FROM:  Enter  the  initiating  organization. 

INFO  COPIES  TO:  Self-explanatory. 

*  ADS:  Enter  the  title  of  the  ADS  of  which  the  pro¬ 
gram  is  a  part. 

PROGRAM  NAME:  Enter  the  name  of  the  program 
in  which  the  problem  or  discrepancy  was  detected. 

•IDENT:  Enter  the  identification  of  the  program  in¬ 
volved. 

RUN  DATE:  Enter  the  date  the  program  was  run  in 
which  the  discrepancy  or  error  was  detected. 

POINT  OF  CONTACT:  Enter  the  name  of  the  indi¬ 
vidual  in  the  organization  which  initiated  the  SPR 
who  is  most  familiar  with  the  problem. 

PROBLEM  DESCRIPTION:  Describe  what  the  dis¬ 
crepancy  or  error  is.  and  the  rircumstances  helped 

•Modified  for  MMRR  use  as  follows: 


cause  it.  Tell  what  should  have  happened  if  there 
had  been  no  discrepancy  and  the  impact  of  the  dis¬ 
crepancy. 

COMMENTS:  Indicate  the  urgency  of  the  correction 
and  any  other  pertinent  facts. 

PROBLEM  ANALYSIS:  Describe  the  cause  of  the 
discrepancy  or  error,  the  impact,  and  any  other  pro¬ 
grams  or  data  bases  affected. 

NAME  OF  ANALYST:  Self-explanatory. 

RECOMMENDED  ACTION:  Describe  the  proposed 
corrective  action  (if  necessary),  and  provide  an  esti¬ 
mate  of  the  time  and  resources  required  to  complete 
the  recommended  action. 

APPROVED  OR  DISAPPROVED:  Self-explana¬ 
tory. 

SIGNATURE  OF  APPROVING  OFFICIAL:  Self-ex- 
plana  tory. 

DATE:  Enter  date  of  signature. 

ACTION  TAKEN:  Tell  what  corrective  action  (if 
any)  was  taken. 

DATE  ACTION  COMPLETED:  Self-explanatory. 


1.  CONTROL  NUMBER:  Enter  the  current  block  cycle  number  or  Emergency/Urgent  MDR 

number  (as  applicable)  followed  by  a  sequential  number  assigned  to  the  SPR.  Num¬ 
bers  are  assigned  consecutively  1 - N  for  each  block  cycle  or  Emergency /Urgent 

change . 

EXAMPLE:  04  -  05  identifies  the  5th  SPR  generated  during  block  cycle  4. 

2.  FROM:  Enter  "Same”  if  initiating  organization  is  the  same  as  the  maintaining 
organization. 

3.  ADS:  Enter  system  (i.e.,  ALR-46,  F-15  TEWS,  Etc.) 

4.  IDENT:  Enter  Part  II  Spec  Number  and  name  (or  equivalent). 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


PROGRAM  ANALYSIS 


DATE:  31  JAN  80 


NAME  OF  ANALYST  (Type  or  print) 


RECOMMENDED  ACTION 


□  APPROVED 

□  DISAPPROVED 


DATE 

APPROVING  OFFICIAL  (Type  or  print 

name ) 

DATE  ACTION  COMPLETED 


AF  Form  1775  (reverse) 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  31  JAN  80 


SUPPLEMENTAL  INSTRUCTIONS  FOR  DP  FORM  1696 

MIL-STD-490  INSTRUCTIONS  FOR  COMPLETING  DD  FORM  1696  ARE  MODIFIED  AS  FOLLOWS: 

Block  6.  SCN  numbers  are  to  be  assigned  consecutively  by  lead  engineer, 

Block  8.  Is  changed  to  indicate  block  cycle  change  ID  number. 

Block  11.  Is  to  indicate  whether  document  is  Systems,  Part  I  or  Part  II 
Specification. 

Block  13.  Change  SCN  to  MDR/SPR . 

Block  19.  Indicate  page  and  paragraph  number  (if  applicable). 

Any  blocks  not  applicable,  insert  'N/A\ 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE:  31  JAN  80 


MIL-STD-1490 

1  February  1969 

SPECIFICATION  CHANGE  NOTICE  (subu.ttal  JUTtt 

«.  I b~0  UOMII 

JSCN  PREPARING  ACTIVITY) 


.  KM  MO. 

2 


C3.TaacTu«L  aCf.vitr 
(NOTE  21 


...  <c,  S£H,AL  NUMBERS  Of  *LL  ITEMS 

AFFECTED  fir  THIS  SCN) 


THIS  taoncc  tnrOM<t  OICIPICMft  »*41  IK  *AICl* ICATIOM  IMuMfUO  V*  IK  MMHI  ImO  UviS.OM  LCTTCOI 
MM  IM  AMI  «  IU|  HIM  OUMII.  M  4*611  OiMU.  IT  MIS  KM  MIMC  MU  r^MIMI  KMfM.lM  AMO 
CAMMTIMC  M  S4MC  DAT(  AS  VmIS  SO*.  IK  ’*US  f  IK  4*U  <U«M  MO  OAIIS  1111(0  OCiOM  IM  IK 
******  00  0> AM 6X0  4ACXS.  C0KIMCO  Ml  IN  M9*.lltt(0  races  or  IK  MlCIMJL  issue  or  Tut  ■(VISION 
mm  IM  OLOCW  4.  COiSTiniU  Im|  0U**IMl  «t*SI0M  OT  IMIS  SMCIMCAIICM. 


FACES  CMANCCO  I  I  NO  I  CATC  O(UTlCMS) 


PACES  CHANCED  AMD  TRANSMITTED  HEREWITH 


S 

«•>  II 

a  OCLCTCD 


SUMMARY  OF  CHANCED  PACES 

•v  * 

f 

So,  II 

12  OELETEO 
II 

NOTES: 

l  BLOCKS  2,  4, 1,  t,  t,  H,I3,  B  IS  ARC  SELF-EXPLANATORY 

t.  TYPE  OF  CONTRACTUAL  ACTION  REQUIRED  FOR  IMPLEMENTATION 
OF  THIS  SCN,  O  f.,  CCN,  SUPPLEMENTAL  AGREEMENT,  ETC. 


TIOMICA  CCMQA'Ua 


(PROCURING  ACTIVITY  SIGNATURE) 


DD  , 1696 


W  t*4i«e«ve  e4.«  uiliti  #«|i  'A*  UOivalM  *44*4  Ml* 


Specifieetion  Change  Notice 
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CONTINUATION  SHEET _ DATE:  31  JAN  80 

MDR/SPR  CHECKLIST  INSTRUCTIONS 

Block  1.  Briefly  state  a  functional  description  of  MDR/SPR  for  easy 

REFERENCE. 

Block  2.  Enter  date  of  MDR  or  SPR. 

Block  3.  Enter  the  identification  number  of  the  MDR  or  SPR.  If  hold  over 

FROM  PREVIOUS  CYCLE/  THEN  CHECK  BOX  AND  ATTACH  THE  ORIGINAL  MDR 

OR  SPR. 

Block  Check  (1  block  only)  the  appropriate  priority.  If  routine,  then 
ENTER  THE  BLOCK  CYCLE  NUMBER  WHEN  THE  MDR/SPR  WILL  BE  PROCESSED. 

Block  5.  Enter  the  MIP  Number  this  MDR  or  SPR  was  assigned. 

Block  6.  Enter  the  engineer  assigned  to  this  MIP. 

Block  7.  Enter  the  scheduled  date  for  Screening  Panel  review.  When  review 

is  COMPLETED.  ENTER  THIS  DATE  WITH  THE  LETTER  "C"  NEXT  TO  THE 
DATE;  I.E.,  16  SEP  79 

17  Sep  79  C 

Block  8.  Check  box  to  indicate  whether  change  is  a  new  requirement  or  is  a 

DEFICIENCY. 

Block  9.  Indicate  whether  user  requirements  need  more  clarification.  If 

YES/  THEN  ATTACH  CORRESPONDENCE  WITH  THE  USER  (l.E./  MESSAGES. 

MEMOS  OF  TELEPHONE  CONVERSATIONS.  ETC.).  CHECK  BOX  (TO  RIGHT  OF 
YES)  WHEN  THE  REVISED  MDR  IS  RECEIVED  (AND  ATTACH  IT  TO  CHECKLIST). 

Block  10.  Indicate  which  areas  are  affected  by  the  MDR/SPR  request. 

Block  11A. 

Indicate  the  MDR/SPR ' s  status  as  determined  during  reviews  by  the 
Screening  Panel.  CPCSB,  and  User  Command. 
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PREDICTIVE  SOFTWARE  COST  MODEL 

MDR/SPR  CHECKLIST 


CONTINUATION  SHEET 


DATE:  31  JAN  80 


1.  TITLE: 


3.  IDENTIFICATION: 

□  MDR  NO, _ 

Q  SPR  NO. _ 

□  HOLD  OVER  (ATTACH  ORIGINAL) 


5.  MIP  NUMBER: 


6.  ENGINEER  ASSIGNED; 


2.  DATE: 


4.  PRIORITY: 

—  □  EMERGENCY 

_  □  URENT 

Q  ROUTINE  (BLOCK  CYCLE: 


7,  SCRENING  PANEL  REVIEW  DATE: 


8.  CHANGE  IS:  □  NEW  REQUIREMENT  □  DEFICIENCY 


9.  FUNCTIONAL  REQUIREMENT  NEEDS  CLARIFICATION: 

□  NO 

□  YES  (ATTACH  MESSAGE)  □  REVISED  MDR  ATTACHED 


0.  AFFECTED  WORK  AREAS:  I  MANHOUR  EST.  (ENGR) 


DESIGN  TEST 


SOFTWARE 


HARDWARE 


LOGISTICS 


ATE 


OTHER 


1IA.  MDR/SPR  STATUS: 

SCREENING  PANEL  □  ACCEPTED  □  DELETED  □  HELD  OVER 
USER  REPRESENTATIVE  □  ACCEPTED  □  DELETED  □  HELD  OVER 
CPCSB  (SRR)  □  ACCEPTED  □  DELETED  □  HELD  OVER 


SIGNATURES  AND  DATES: 
SCREENING  PANEL  CHAIRMAN, 
USER  COMMAND  REP, 


12.  IF  MDR/SPR  WAS  HELD  OVER  OR  DELETED  THEN  BRIEFLY  STATE  WHY. 


PREDICTIVE  SOFTWARE  COST  MODEL 

CONTINUATION  SHEET _ DATE:  31  JAN  80 

CHANGE  PROCESS  CHECKLIST  INSTRUCTIONS 
SECTION  1:  IDENTIFICATION 
BLOCK  1:  Enter  the  Block  Cycle  Number, 

BLOCK  2:  A,  Enter  system  name  (i.e.,  ALR-62)  and  version. 

B.  Check  appropriate  command. 

C.  Indicate  nomenclature. 

BLOCK  3:  Enter  the  inclusive  dates  of  present  Block  Cycle.  Same  as  Block  3 
of  the  Change  Request  Form. 

BLOCK  A:  A.  Enter  the  quantity  of  MDR/SPR's  which  were  held  over  from 
previous  cycles.  Enter  0  if  none. 

B.  Enter  the  quantity  of  new  MDR/SPR's  requested  for  present  cycle. 

C,  Total  of  A  and  B. 

BLOCK  5:  A.  Enter  old  (current)  CPIN  and  date. 

B.  Enter  new  CPIN  (when  assigned)  and  date. 

BLOCK  6:  User  Command  Representative  signature  (and  date)  indicating  approval 
of  the  prioritization  of  the  Change  Requests  listed  on  the  Change 
Request  Form;  "A"  if  SAC  and  "B"  if  TAC. 

BLOCK  7:  Print  or  type  in  the  names  and  symbols  of  the  Screening  Panel  Members 
PRESENT  FOR  THE  SRR  AND  THE  FOR.  ENTER  "Same"  UNDER  THE  FOR  IF  THE 
MEMBER  IS  UNCHANGED  FROM  THE  SRR. 

BLOCK  8:  Same  as  Block  7  except  for  Unit/Section  Chiefs. 

BLXK  9:  Same  as  Block  7  except  for  CPCSB  Members. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET _ DATE:  31  -JAN 

SECT] ON  2:  REVIEWS  AND  AUDITS 

BLOCK  1:  A.  Check  block  as  item  is  accomplished. 

B.  Enter  date  of  SRR. 

C.  CPCSB  Chairman  acceptance  signature. 

BLOCK  2:  A,  Check  box  as  item  is  accomplished. 

B.  Enter  date  of  SDR/FDR. 

C,  Approval,  signatures  as  indicated. 

BLOCK  3:  A.  Check  box  as  item  is  accomplished. 

B.  Enter  date  of  PVR. 

C.  Approval  signatures  as  indicated. 

BLOCK  A:  A.  Check  box  as  item  is  accomplished. 

B,  Enter  date  of  FCA/PCA, 

C.  Approval  signatures  as  indicated. 

BLOCK  5:  A.  Check  box  as  item  is  accomplished. 

B.  Enter  date  of  FOR. 

C.  CPCSB  Chairman  approval  signature. 

SECTION  3:  IhST  COMPLIANCE  MATRIX 

BLOCK  1:  Enter  system  name. 

BLOCK  2:  Test  required  box;  for  each  check  "Y"  if  Yes 

check  "N"  if  No. 

BLOCK  3:  Test  Plans:  Enter  date  test  plans  due; 

Enter  approval  of  test  plans  by  signature; 
Enter  date  of  approval. 

BLOCK  A:  Test  Procedures:  Same  as  Number  3. 

BLOCK  5:  Test  Reports:  Same  as  Number  3.  Also  indicate  the  number 

OF  SPR'S  GENERATED  DURING  EACH  LEVEL  OF  TESTING, 


PREDICTIVE  SOFTWARE  COST  MODEL 

CHANGE  PROCESS  CHECKLIST 


SECTION  1:  IDENTIFICATION 


31  JAN  80 


1.  BLOCK  CYCLE  NO: _ 


2A.  SYSTEM _ VER_ 

B,  COMMAND:  Q  SAC  Q  TAC 

C.  CPC  I  NOMENCLATURE: 


NOTE:  This  form  for  ro< ft i ne 

PRIORITY  CHANGES  ONLY 


3.  BLOCK  CYCLE  DATES: 

A.  ESTABLISHED: _ 

B.  SUBMISSION  CUTOFF: 


4.  NUMBER  OF  MDR/SPR's: 

5.  CONFIGURATION  MANAGEMENT  USE  ONLY 

A.  NO.  HELD  OVER 

A,  OLD  CPIN:  DATE 

B.  NEW  CANDIDATES 

B.  NEW  CPIN:  DATE 

C.  TOTAL 

6.  USER  COMMAND  PRIORITIZATION: 

DATE 

A.  fl  SAC 

B.  □  TAC 

7.  SCREENING  PANEL  MEMBERS 


Equipment  Specialist  (Chariman) 

Log  Officer 

Lead  Engineer 

ATE  Engineer 

(Others) 


ACCEPTANCE  (SRR) 

NAME/ SYMBOL 


APPROVAL  (FOR) 
name/symbol 


8A.  Unit  Chief  - 

B.  Section  Chief _ — - - - 


9.  COMPUTER  PROGRAM  CONFIGURATION  SUB-BOARD  MEMBERS  (CPCSB) 


Division  Chief  (Chairman)  - 

System  Engineering  Manager  - 

Technical  Services  Manager  - 

Production  Manager  _ 

Logistics  Manager  _ 

ATE  Software  Manager  _ 

User  Command  Representative  _ 


PREDICTIVE  SOFTWARE  COST  MODEL 

CHANGE  PROCESS  CHECKLIST  w 

SECTION  2: _ REVIEWS  AND  AUDITS _ System 


1A.  SYSTEM  REQUIREMENT  REVIEW  (SRR) 

IB.  DATE: 

— 

Change  Request  Index  (Prioritized) 

MDR/SPR  Checklists 

MIP  Forms  A8 

User  Command  Minutes  (If  Applicable) 

System  Specification  Redlines  Approved 
Implementation  Plan  Approved 

AFLC  Form  75  Total  Manhour  Estimate 

1C .  CPCSB  Acceptance : 

Chairman 

2A.  SYSTEM/PRELIMINARY  DESIGN  REVIEW  (SDR/PDR) 

2B.  DATE: 

— 

Part  I  Specification  Redlines  Approved 

Test  Compliance  Matrix  Approved 

2C.  Screening  Panel  Approval: 

Chairman 

Lead  Engineer 

Unit  Chief 

3A.  PRODUCT  VERIFICATION  REVIEW  (PVR) 

3B.  DATE: 

— 

Part  II  Specification  Redlines  Approved 
SPR's  Correctly  Dispositioned 

Test  Compliance  Matrix  Approved 

3C.  Screening  Panel  Approval: 

Chairman 

— 

IfadFnginfer 

Unit  Chief 

4A.  FUNCTIONAL/PHYSICAL  CONFIGURATION  AUDIT  (FCA/PCA) 

4 B.  DATE: 

— 

Part  I  Specification  Approved 

Part  II  Specification  Approved 

FCA  Report  Approved  (Test  Synopsis) 

Test  Compliance  Matrix  Approved 

SPR's  Correctly  Dispositioned 

PCA  Report  Approved 

C,  Screening  Panel  Approval: 

Chairman 

Lead  Engineer 

Unit  Chief 

— 

5A,  FORMAL  QUALIFICATION  REVIEW  (FOR) 

5B.  DATE: 

— 

FCA/PCA  Reports  Approved 

Change  Request  Index 

Open  MDR's  Correctly  Dispositioned 

Open  SPR's  Correctly  Dispositioned 

AFLC  Form  75  Completed 

Test  Compliance  Matrix  Approved 

5C,  CPCSB  Approval: 

Chairman 

— 
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PREDICTIVE  SOFTWARE  COST  MODEL 

CONTINUATION  SHEET _ _  DATE:  31  JAN  80 


EMERGENCY/URGENT  CHANGE  PROCESS  CHECKLIST  INSTRUCTIONS 
BLOCK  1:  Check  correct  priority. 

BLOCK  2:  Enter  date  change  request  was  received. 

BLOCK  3:  A.  Enter  system  name  and  version  (if  applicable). 

B.  Check  appropriate  command. 

C.  Enter  CPC  I  nomenclature. 

BLOCK  A:  A.  Enter  old  CPIN  Number  with  date  of  release. 

B.  Enter  new  CPIN  Number  with  date  of  release. 

BLOCK  5:  Print  or  type  in  the  names  and  office  symbols  of  the  Screening 
Panel  members  (or  alternates). 

BLOCK  6:  Print  or  type  in  the  name  and  office  symbol  of  the  Unit  and 
Section  Chief. 

BLOCK  7:  Print  or  type  in  the  names  and  office  symbols  of  the  CPCSB  members 
(or  alternates). 

BLOCK  8:  Check  each  block  as  items  are  completed.  Approval  of  all  checked 

ITEMS  IS  INDICATED  BY  THE  SIGNATURES  OF  THE  EQUIPMENT  SPECIALIST, 

Lead  Engineer,  and  Unit  Chief. 

BLOCK  9:  Check  appropriate  block  indicating  the  CPCSB 's  decision.  The 
CPCSB  Chairman  signs  and  dates  the  decision. 


PREDICT/VE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET _  DATE:  31  JAN  80 


Block  11B. 

After  checking  the  appropriate  box  in  11A,  the  Screening  Panel 
Chairman  then  signs  and  dates.  The  same  applies  to  the  User 
Command  Representative. 


Block  12A. 

Briefly  state  why  the  MDR  of  SPR  was  held  over  or  deleted. 


k 


PREDICTIVE  SOFTWARE  COST  MODEL 


EMERGENCY/URGENT  CHANGE  PROCESS  CHECKLIST 

CONTINUATION  SHEET  DATE:  31  JAN  80 


1.  Priority:  U  emergency 

□  URGENT 

2,  Date  Received: 

3,  A.  System  Ver 

9.  Configuration  Management  Use  Oni  y 

B,  Command:  Q  sac  Q  tac 

C,  CPC  I  Nomenclature : 

A.  Old  CPIN:  Date 

B.  New  CPIN:  Date 

5,  SCREENING  PANEL  MEMBERS 

NAME  i  OFFICE  SYMBOL 

Equipment  Specialist  (Chairman) 

Log  Officer 

Lead  Engineer 

ATE  Engineer 

(Others) 


6.  A.  Unit  Chief  _ 

B.  Section  Chief _ — . . . 

7.  COMPUTER  PROGRAM  CONFIGURATION  SUB-BOARD  MEMBERS  (CPCSB) 


Division  Chief  (Chairman) 
System  Engineering  Manager 
Technical  Services  Manager 
Production  Manager 
Logistics  Manager 
ATE  Software  Manager 
User  Command  Representative 


8.  SCREENING  PANEL  APPROVAL  ITEMS 
|~|  scn's  for  specifications 
f~]  system  specification  redlines 

Q  PART  I  SPECIFICATION  REDLINES 
Q  PART  II  SPECIFICATION  REDLINES 
Q  TEST  COMPLIANCE  MATRIX 

□  pca/fca  reports 

□  ALFC  FORM  75 


APPROVAL  SIGNATURES 


Equipment  Specialist 
Lead  Engineer 
Unit  Chief 


9.  CPCSB  DECISION:  □  approved 

CPCSB  CHAIRMAN:  _ 


Q  disapproved 

_  DATE: _ 


A77 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  _  _ DATE:  31  JAN  80 


CHANGE  REQUEST  INDEX  INSTRUCTIONS 

BLOCK  1 

Enter  the  system  name;  i.e.,  ALR-62  V  1,  2,  3 

BLOCK  2 

Enter  the  CP  IN  of  the  OFF  id  be  altered  by  these  changes. 

BLOCK  3 

Block  Established  Date:  Enter  the  submission  cutoff  date  of  the 

PREVIOUS  BLOCK  CYCLE. 

Submission  Cutoff  Date:  Enter  the  date  after  which  no  further 

CHANGE  REQUESTS  WILL  BE  ACCEPTED  FOR  THIS  BLOCK  CYCLE. 

BLOCK  A 

Check  the  box  (one  only)  indicating  the  priority  of  the  changes 
listed  in  Block  5.  If  routine,  then  give  the  Block  Cycle  Number. 

BLOCK  5 

List  each  change  request.  Indicate  whether  it  is  an  MDR  or  SPR 
followed  by  the  ID  Number,  (i.e.,  MDR  062  417  or  SPR  1006). 

BLOCK  6 

Same  as  Block  1  (title)  on  the  MDR/SPR  checklist,  (brief  func¬ 
tional  description). 

BLOCK  7 

Indicate  the  status  of  each  change  request  (i.e.,  action  taken 
by  CPCSB)  and  the  date  of  action  (i.e.,  CA/17  Oct  79). 


NOTE: 


The  above  instructions  for  Blocks  5,  6,  and  7  apply  to  the  Change 
Request  Continuation  Sheet  also, 


CHANGE  REQUEST  INDEX 


>-.w. ......  ..  mh - -  — -•  -  *  -  m  Vi— •  -.■»*-.•  >. •  •- ^ — ***uMfc & ~  ^.*yg m htfc 


PREDICTIVE  SOFTWARE  COST  MODEL  i 


CONTINUATION  SHEET  DATE:  31  JAN  80 


CHANGE  REQUEST  INDEX  (Continuation  Sheet)  System 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET _ DATE:  31  JAN  80 


PCA  REPORT  INSTRUCTIONS 

1:  Enter  system  name,  date  of  PCA,  system  (current)  CPIN  and  title  (CPIN 
nomenclature) . 

2:  Block  1.  Check  Blocks  A,  B,  C,  and  D  as  each  is  accomplished  by  the 
Screening  Panel. 

Block  2.  Check  block  as  item  is  accomplished  and  approved  by  the 
Screening  Panel. 

Block  3.  Check  block  as  item  is  accomplished. 

3:  Approval  signatures  as  indicated. 


PREDICTIVE  SOFTWARE  COST  MODEL 


PHYSICAL  CONFIGURATION  AUDIT  (PCA)  REPORT 

CONTINUATION  SHEET  DATE:  31  JAN  80 


SYSTEM 

DATE 

CPIN  NO. 

TITLE 

1.  PART  II  SPECIFICATION  REVIEWED  FOR  FORMAT  AND  COMPLETENESS 

A.  Q  Top  Level  CPC  I  Flow  Charts  and  Computer  Program  Component  (CPC)  Flow  Charts 
Reviewed  for  Proper  Entries.  Symbols,  and  Labels. 


B.  □  CPC  Flow  Charts  Consistent  with  Source  Coded  Program. 


C.  □  Computer  Listing  in  Part  II  Specification  Checked  with  Current  Listing 

Made  at  PCA. 

D.  Q  MDR's.  SPR's,  SCN's.  DCN's  Traced  to  Changes  in  Specifications. 

2.  □  Checked  Manuals  (Users,  Programmers,  etc.)  for  Proper  Entry  if  Affected  by 

Change . 

3.  Q  Verified  that  FCA  Reported  Discrepancies  are  Resolved. 

PCA  CONDUCTED  BY  REMARKS: 

Equipment  Specialist _ _ 

Lead  Engineer  - - 

Unit  Chief  -  - 

Other  _ 


NOTE:  Any  Items  Not  Applicable,  State  N/A. 


PREDICTIVE  SOFTWARE  COST  MODEL 

CONTINUATION  SHEET _ DATE:  31  JAN  80 

FCA  REPORT  INSTRUCTIONS 

1:  Enter  system  name. 

2:  Enter  Part  I  Specification  Number. 

3:  Enter  the  paragraph  number  (i.e.,  3.2.1)  in  the  Part  1  Specification 
of  interest. 

4:  Briefly  state  the  requirement  called  for  in  the  paragraph. 

5:  Briefly  state  how  the  given  requirement  was  tested  (i.e.,  ISS  Simulation. 
EWOLS,  etc.). 

6:  Briefly  state  any  results  (i.e.,  passed  or  failed). 

7:  Enter  the  report  number  in  which  the  testing  is  documented. 

8:  Signature  of  person  who  completed  the  FCA  Report, 

9:  Enter  the  Part  II  Specification  Number. 


FCA  REPORT 

SPECIFICATION  COMPLIANCE  MATRIX 


COMPLETED  BY  PART  II  SPEC  NQ. 


PREDICTIVE  SOFTWARE  COST  MODEL 

CONTINUATION  SHEET _ DATE:  31  JAN  80 

INSTRUCTIONS  FOR  COMPLETING  DOCUMENT  CHANGE  NOTICE  (DCN) 

ISSUE  DATE:  Enter  the  date  this  DCN  was  issued. 

DOCUMENT  NO, :  Enter  the  number  of  the  document  which  is  being  changed  by  this 
DCN. 

DOCUMENT:  Enter  the  name  of  the  document.  (Include  system  name.) 

CPCKS):  Enter  the  CPCI's  of  the  system  affected  by  this  DCN. 

ISSUED  BY:  Enter  the  name  and  organization  of  the  person(s)  issuing  the  DCN. 
APPROVED:  Enter  the  lead  engineer  approval  signature. 


D 

x  (Deleted) 
(Superceded) 
(Added) 


PAGE  NO. :  Number  of  the  page  altered. 

S:  Page  was  superceded  (Enter  an  "X"). 
A:  Page  was  added  (Enter  an  "X"). 

D:  Page  was  deleted  (Enter  an  "X"). 

i.e./  Page  No. _ S  A 
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INSTRUCTIONS  FOR  COMPLETING  THE  COMPUTER  PROGRAM  CLASS  II  CHANGE  REPORT 
ORIGINATOR:  Enter  the  name  of  the  organization  which  originated  this  report. 
DATE:  Enter  the  date  this  report  was  originated. 


SPEC  NO. /PART:  Enter  the  specification  number  and  part  number  (when  applicable) 

OF  THE  SPECIFICATION  WHICH  THIS  CHANGE  REPORT  REFERS  TO. 

CR  NO.:  Enter  the  change  report  number  of  this  report.  Start  with  1  and 

NUMBER  FOLLOWING  CHANGE  REPORTS  SEQUENTIALLY. 

REVISION:  Enter  the  revision  code  (letter  or  number)  of  the  document  this 

REPORT  REFERS  TO. 

CPC I  NOMENCLATURE:  Enter  the  nomenclature  of  the  CPCI  referred  to  by  this 

REPORT. 

TITLE  OF  CHANGE:  Enter  a  short  functional  description  of  the  change. 

DESCRIPTION  OF  CHANGE:  Describe  in  detail  the  Class  II  Change  requested  by 
this  report. 

JUSTIFICATION:  Describe  briefly  your  justification  for  requesting  this 
particular  change  in  the  documentation. 

RELEASED  BY:  Enter  the  name  and  organizational  symbol  of  the  person  releasing 
this  report.  (Usually  the  lead  engineer.) 

AUTHOR :  Enter  the  name  and  organizational  symbol  of  the  person  who  initiated 
this  report. 

CLASSIFICATION  APPROVAL:  Enter  the  signature  of  the  individual  who  approved 
this  as  a  Class  II  change.  (Usually  the  lead  engineer.) 

DATE:  Enter  the  date  of  release  of  this  report. 
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ORIGINATOR 

DATE 

SPEC  NO. /PART 

CR  NO. 

REV 

CORR 

CPC!  NOMENCLATURE 


TITLE  OF  CHANGE 


DESCRIPTION  OF  CHANGE 


JUSTIFICATION 


RELEASED  BY 

AUTHOR 

CLASSIFICATION  APPROVAL 

DATE 
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R*  Hyp  D*Ta  pORMS  •  SPtclAL  instructions 


this  section  delineates  onlt  The  deviations  from  the  normal 
INSTRUCTIONS  FOR  COMPLETING  THE  MODIFICATION  DaTa  FORMS  (PREYED 
BY  TMt  EQUIPMENT  SPECIALIST)  OUE  TO  A  SOFTWARE  ChaN6E.  ThESE 
INSTRUCTIONS  SHALL  BE  FOLLOWED  WHEN  A  CHANGE  PaCKaGE  CONSISTS  OF; 

1 •  A  TCTO  ONLY  (TO  CONVERSION  TO  CPIN) 

2.  TCTO  AND  MEDIA  (TaP|)  (SOFTWARE  CHANGE) 

3.  TCTO  AND  KIT  (PROM  CHANGE) 


R.l.  AFLC  FORM  873 


part  i:  HEADING  INFORMATION,  TECHNICAL  ORDER  (TO)  AND  DATA  CODE 
NUMBERS  WILL  BE  ASSIGNED,  and  PROCESSED  NORMALLY.  RESCISSION  DATA 
WILL  NOT  BE  LESS  THAN  NINE  MONTHS  AFTER  *T0<  ISSUE*  I  THE  NINE 
MONTHS  MILL  BE  THE  NORM,  EXCEPTIONS  WILL  OCCUR.) 


PART  II :  compliance  information.  WHEN  WORK  WILL  BE  accomplished* 
•AS  0  irected  by  using  activity  BUT  not  LATER  THAN  00  days  after 
RECEIPT  OF  TIME  COMPLIANCE  TECHNICAL  ORDER  (TCTO).*  ( MN£  WILL 
change  editorially  FORMS  NOT  COMPLETED  ACCORDINGLY. I 

PART  1111  SUPPLY  INFORMATION.  AFLC  FORM  87H  IS  NOT  REQUIRED* 
(SOFTWARE  CHANGE  ONLY.  NO  HARDWARE  INVOLVED*) 

PART  IV:  KIT  INSTALLATION  TOOLS.  NOT  REQUIRED* 


PART  VI  MAN-HOURS  REQUIRED.  TOTAL* 


PART  Vi!  WEIGHT  AND  BALANCE.  N/A 

PART  VIII  FORM  ENTRY  REQUIREMENT.  AFTO  FORM  349  REPORTING  WILL 
BE  REQUIRED.  ♦  AN  AFTO  FORM  349  WILL  BE  SUBMITTED  FOR  EACH 
AFFECTED  TEST  TAPE  (LISTED  IN  PARAGRAPH  U  OF  TCTo)  AFTER  TCTO 
COMPLIANCE**  DUPLICATE  COPIES  OF  TAPES  LISTED  IN  PARAGRAPH  )A 
WILL  BE  REPORTED  INDIVIDUALLY* 


part  vim  Functional  check,  not  required. 

part  ix;  technical  orders  affected*  complete  as  required* 

part  x;  KIT  proof  testing,  not  required. 

PART  XH  MODIFICATION  MARKING.  NOT  REQUIRED. 
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remarks:  complete  as  required. 


M • 2 •  WR-ALC  FORM  309 


THIS  FORM  is  REQUIRED  FOR  SUBMISSION  TO  MHSK.  A  COPY  OF  THE  AFLC 
FORM  873  MUST  BE  SUBMITTED  WITH  THE  WR-ALC  FORM  3n9  TO  HHMSK* 
CAREFUL  ATTENTION  MUST  BE  GIVEN  TO  THE  QUANTITY.  YOU  AR£  REMINOED 
THE  QUANTITY  REFLECTED  HERE  WILL  BE  INPUT  INTO  THE  00*6  TO  REFLECT 

status  of  compliance*  mmrp  will  be  relying  on  this  product  in 
determining  COMPLIANCE  completion,  mmeot  will  upon  request 
provide  information  they  have  available  to  assist  mmrr  in 
OBTAINING  QUANTITIES  TO  BE  INPUT. 


9*3*  AFTO  FORM  82 


NOT  REQUIRED  IN  CONVERSION  FROM  COMPUTER  TAPE  ICTl  TO  CPIN  OR  FOR 
SOFTWARE  CHANGES. 


9.9»  AFLC  FORM  879 


NOT  REQUIRED  IN  CONVERSION  FROM  COMPUTER  TAPE  | CT »  TO  CPIN  OR  FOR 
SOFTWARE  CHANGES. 


9*5*  AFLC  FORM  2&2 


COMPLETE  AS  CUSTOMARY  WITH  THE  FOLLOWING  EXCEPTIONS  AND  REMARKS! 

•  REMARKS  BLOCK!  INCLUDE  PRIORITY  and  the  STATEMENT 
’RESULT  OF  TCTO-— ♦ 

.  SAFETY  ENGINEERING  GROUP  (SEGI  COORDINATION  IS  NOT  REQUIREO 
(THIS  ACTION  WAS  COORDINATED  WITH  SEG  ON  20  JUNE  19791. 

•  CAREFUL  ATTENTION  MUST  BE  GIVEN  TO  THE  STRUCTURE 

AND  TYPING  OF  ThE  CPINS.  THE  ALIGNMENT  jS  IMPORTANT. 

.  IF  THE  »T0*  IS  CLASSIFIED,  INCLUDE  THE  STATEMENT! 

•THIS  IS  AN  UNCLASSIFIED  CHANGE  TO  A  CLASSIFIED  TO* 

IF  APPLICABLE* 

•  an  aflc  Form  252  will  be  required  For  every  »to» 
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K£FEr£NC£0  on  TH£  AFJ.C  F0Rrt  873. 

•  the  computer  program  identification  number  ,cpin, 

D*Tfc  WILL  BE  TH£  CPIn  *E8uEST  DA7£* 

M  »  6  »  AFLC  FORM  875 


time  COMPLIANCE  TECHNICAL  order  PROGRAMMING  DOCUMENTS 

THE  HEAOInG  is  cOMPLETEO  NORMALLY  BUT  USE  SAME  COMMENTS  aS  USED  ON 
AFLC  FORM  873  IN  WHEN  TO  BE  ACCOMPLISHED  BLOCK.  MMRR  WILL 
COMPLETE  AS  ROUTINE  THROUGH  COLUMN  G.  WHEN  REOUinEO.  MMrP  WILL 
COMPLETE  FROM  COLUMN  1,  COLUMNS  H  AND  K  WILL  S£  USED  FOR  OATES 
FURNISHED  By  mMEC/MMED. 

SECTION  IA.  MMRR  WILL  CHECK  COLUMN  D»  MMRP  WIlL  CHECK  COLUMN  I 

AND  MMEDT  WILL  FURNISH  date  scheduled  FOR  TCTU  AVAILABILITY.  THIS 
DATE  WILL  BE  FURNISHED  AT  THE  PRERELEASE  REVIEW  GROUP  IPRRGl 
MEET  ING  OR  VIA  TELEPHONE  IF  A  PRRG  MEETING  IS  nOT  HELD. 

SECTION  IF*  SEG  COORDINATION  IS  NOT  REQUIRED  ON  a  CONVERSION 
TCTO. 

SECTION  2.  COMPLETE  as  requiheo.  line  e  will  require  a  date  from 
MMEC  IF  tape  reproduction  is  TO  be  oone  by  hmec. 

SECTIONS  3.  **.  St  A*  7 1  8,  AN0  9  WILL  BE  ANNOTATED  AS  NOT 
APPLICABLE. 

SECTION  10.  THIS  SECTION  WILL  b£  COMPLETED  AS  APPLICABLE* 

SECTIONS  It.  12.  1 3 »  II.  15.  16.  1 7 •  lB,  |9.  2o.  21.  AN0  27  WILL 
BE  ANNOTATED  AS  NOT  APPLICABLE. 

SECTION  231 

LINE  B»  CROSS  OUT  AFLC  FORM  878  AS  IT  IS  NOT  APPLICABLE.  ACTIONS 
REQUIRED  AND  COMPLETEO  WILL  PERTAIN  ONLY  TO  THE  AFLC  FORm  873. 

LINE  C.  TAPE  OVER  PRINTED  SEGMENT  IN  COLUMN  MTEm  B*.  TYPE  IN 

•master  tape  or  master  media  available*,  if  media  has  been 

FURNISHEO  PRIOR  TO  THE  COMPLETION  OF  THE  FORM,  GIVE  DATE  AND 
ANNOTATE  OFFICE  TO  WHICH  Ta**E  WAS  DELIVERED  IN  COLUMN  H.  IF  A 

part  of  the  package  being  prepared,  so  annotate. 

LINE  0.  TAPE  OVER  PRINTED  SEGMENT  IN  COLUMNS  ’ITEM  B*  AND 
•REFERENCE  C*.  TYPE  IN  ’REPRODUCED  CPIN  MEDIA  AVAILABLE*.  IT  IS 
NOT  EXPECTED  THAT  IN  HOST  CASES  THE  REPRODUCED  TAPE  wlLt  BE 
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AVAILABLE  At  THE  TIME  OF  THE  COMPLETION  OF  THE  AFlC  FORM  8  75  • 
HOWEVER,  MMec  WILL  FUMNISH  A  DATE  FOR  COLUMN  H  AT  THE  PRR6  MEET  OR 
VIA  TELEPHONE.  ON  A  CONVERSION  CHECK  N/A.  MMRP  wlLL  RETAIN 
RESPONSIBILITY  FOR  CONCURRENCY  RELEASE.  ACCORO I  N(iL  Y ,  MMEO  AND 

mmec  hill  obtain  mmrp  coordination  prior  to  the  release  of 
tcto/manual  chances  and  cpin  media. 

FLIGHT  manual  COORDINATION 

mmsrd  (flight  manual)  coordination  is  not  required*  (This  was 

COORDINATED  with  MMSRD  ON  20  JUNE  1979. 

H#7.  drafting  of  THE  TCTqI 


rescission  oate:  nine  months  WILL  be  used  as  a  standard 

(EXCEPTIONS  WILL  OCCUR). 

WHEN  TO  BE  ACCOMPLISHED!  *AS  DIRECTED  BY  USING  ACTIVITY  BUT  NOT 
LATER  THAN  90  DAYS  AFTER  RECEIPT  OF  THIS  TECHNICAL  ORDER.* 

HOW  WORK  IS  ACCOMPLISHED!  THE  FORMAT  TO  RE  PLACED  ON  LABELS  IS 
CRITICAL  OUE  TO  THE  LIMITED  SPACE  ON  A  LABEL  (FIVE  LINES  ARC 
REQUIRED.  NO  MORE  CAN  BE  USED).  DISPLAY  INFORMATION  AS  FOLLOWS! 

CPIN!  OTO  (ONLY  33  SPACES  AVAILABLE) 

P/N!  (ONLY  23  SPACES  AVAILABLE) 

NOUN!  (35  SPACES  AVAILABLE) 

RELATED  MANUAL!  (20  SPACES) 

REPLACES!  (COMPUTER  TAPE  (CT)  AND  DATE  -  37  SPACES  AVAILABLE) 

(LINE  TITLE  COUNT  IS  NOT  INCLUDED  IN  AVAILABLE  SPACE  ACCOUNT. 
CAREFUL  PROOFREADING  IS  NECESSARY.) 

records: 

•action  required  on  MAINTENANCE  records,  an  afto  FORM  3r9  will  be 
SUBMITTED  For  each  affected  computer  TEST  tape  listed  in  paragraph 
1A  AFTER  ACCOMPLISHMENT  OF  THIS  TECHNICAL  ORDER.  OUPLICaTE  COPIES 
of  tapes  listed  in  paragraph  ia  *ill  be  reported  individually.* 
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DESCRIPTION  OP  SKILL  LEVEL  AND  TYPE  (AF/CS/CONT)  OF  PERSONNEL  MAINTAINING  THIS  PACKAGE 

The  usual  GS-855  electronic  engineer  is  used  in  supporting  EW  software. 

In  addition,  MMRR  uses  GS-1550  computer  scientists.  Below  is  the  position 
discription  for  a  GS-1550-12. 


POSITION  DESCRIPTION  FOR 
COMPUTER  SCIENTIST, 
GS-1550-12 


Introduction 

The  purpose  of  this  position  is  to  serve  as  a  Computer  Scientist  to  perform 
professional  research  and  development  projects  in  support  of  reprogrammable, 
computer  controlled  Electronic  Warfare  Avionics  systems  and  related  support 
equipment  and  software  for  which  Warner  Robins  ALC  is  prime. 

Duties  and  Responsibilities 

1.  Incumbent  develops,  coordinates  and  carries  through  to  completion  computer 
science  projects  and  tasks  of  large  scope  containing  several  complex  features 
Conducts  professional  research  and  development  work  to  evolve  new  methods 
and  techniques  to  store,  manipulate,  transform,  or  present  information  by 
means  of  digital  computers.  Develops  or  originates  completely  new  features, 
in  addition  to  improving,  extending,  or  validating  currently  known  prece¬ 
dents,  data,  methods  or  techniques.  In  accomplishing  the  above,  the  incum¬ 
bent  is  responsible  for  development  of  new  or  improved  computer  methods, 
techniques,  principles,  or  concepts. 

2.  Serves  as  a  professional  computer  scientist  performing  research  and  devel¬ 
opment.  Assures  integrity  and  compatibility  of  the  development  with  program 
managers,  system  project  managers,  and  other  user  elements  as  required. 

Plans  and  schedules  all  assigned  professional  computer  science  development 
projects  and  tasks,  including  investigation,  analysis,  design,  coding, 
debugging,  testing,  evaluation,  integration,  documentation,  and  implementa¬ 
tion.  Prepares  requirements  documents,  design  specifications,  test  proce¬ 
dures,  implementation  specifications  and  software  documentation.  Maintains 
configuration  control  during  development  and  coordinates  or  performs  the 
update  of  all  documentation. 

3.  Incumbent  must  be  proficient  in  the  programming  of  computers  at  ^the  maci  u 
and/or  assembly  language  level,  as  well  as  use  of  higher  level  languages 
Due  to  the  complex  interface  between  the  software  and  hardware  of  compute, 
controlled  systems,  this  programming  is  accomplished  utilizing  knowledge 
of  hardware  operations  and  limitations  created  by  hardware  design.  Works 
closely  with  hardware  oriented  systems/project  engineer  to  insure  a  unified 
solution  to  problems  is  accomplished  in  the  most  effective  manner. 

4.  Conducts  research  in  computational  complexity,  analyzes  algorithms  for  data 
structures  that  lead  to  highly  efficient  combinational  power  of  different 
computer  models.  Develops  advanced  concepts  of  automation  information  pro¬ 
cessing  developing,  control  and  transfer. 
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5.  Incumbent  is  responsible  for  advanced  or  exploratory  development  work 
wherein  digital  computers  are  employed  in  support  of  data  acquisition/ 
reduction,  record  keeping,  real-time  control/monitoring,  modeling  and 
simulation,  and  resource  allocation.  Scope  of  assigned  task  or  project 
effort  is  broad  in  that  all  tasks  or  projects  consider,  as  applicable, 
the  support  resources,  host  computers,  systems  interfaces,  support  soft¬ 
ware  interfaces,  specialized  operating  system  configurations,  documen¬ 
tation,  and  validation/verification. 

6.  Prepares  contractual  proposals  and  associated  specifications  and  work 
orders.  Monitors  and  maintains  close  liaison  between  contractor  and 
Air  Force  activities  associated  with  support  of  contracts  involving 
development  of  new  and  improved  concepts,  principles,  and  techniques 
that  advance  the  body  of  knowledge  associated  with  digital  computers. 
Reviews,  evaluates  and  advises  on  the  effectiveness,  technical  adequacy 
and  suitability  of  work  and  proposals  of  lower  grade  personnel  related 
to  such  development.  Evaluates  vendor  proposals  for  requirements, 
feasibility,  completeness,  accuracy,  cost  and  operational  and  logistics 
impact . 

7.  Scope  of  personal  contacts  is  broad  as  the  incumbent  consults  with  IM, 

SM,  Procurement,  Shop,  Contractor,  and  operating  command  personnel. 

8.  Performs  other  related  duties  as  assigned. 

Controls  Over  Work 

1.  Works  under  general  supervision.  Assignments  are  given  by  Section/Unit 
Chiei  or  higher  grade  engineer  or  Computer  Scientist  with  instructions 

as  to  the  purpose  of  the  work  and  possible  complex  features.  The  feasible 
approach  and  solution  are  the  responsibility  of  the  incumbent. 

2.  Little  guidance  is  given  except  on  cases  of  controversial  complex  features 
and  policy. 

3.  Completed  work  is  reviewed  for  overall  technical  adequacy  and  conformance 
with  the  objectives  of  the  assignment.  When  there  is  serious  consequence 
of  error,  a  complete  independent  check  may  be  made  of  programs,  drawings, 
computations,  etc. 

Other  Significant  Facts 

1.  Position  requires  that  incumbent  participate  in  flight  test  as  assigned. 

2.  Incumbent  is  subject  to  TDY  in  CONUS  or  overseas  for  periods  up  to  several 
weeks.  Specialized  training  may  necessitate  TDY  or  PCS  for  up  to  one  year 
at  other  government  or  contractor's  plants. 

3.  Military  aircraft  will  be  used,  when  available,  to  perform  TDY.  Commercial 
aircraft  or  ether  modes  of  transportation  will  be  used  when  military 
aircraft  is  not  available. 

4.  Fields  of  engineering:  Electronic  -  25  percent.  Electrical  -  5  percent, 
Computer  Science/Programming  -  70  percent. 
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5.  Specializations  required  include:  Bachelor's  degree  in  computer  science, 
engineering,  physics,  mathematics,  or  other  technical  area  and  experience 
in  program  development  and  testing,  computer  technology,  programming  lan¬ 
guages,  simulation  modeling,  operating  systems,  data  structures,  input/ 
output  compilers/assemblers,  integration  of  computer  controlled  hardware 
and  software,  software  documentation,  and  configuration  management. 

6.  Subject  to  call  during  off-duty  hours  and  an  occasional  requirement  for 
weekend  and  holiday  work. 
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COMPUTER  FACILITIES  (Type,  Quantity,  Application,  Cost  &  Usage) 


DATE:  31  JAN  80 


A  typical  Electronic  Warfare  Integration  Support  System  USS)  is  diagrammed 
on  page  G-58. 

For  each  software-controlled  EW  system  there  will  be  a  Resources  Acquisitio 
Management  Plan  (RAMP).  Its  contents  are  detailed  below. 


RESOURCES  ACQUISITION  MANAGEMENT  PLAN 
TABLE  OF  CONTENTS 


Foreword 


Equipment  Requirements 

1.1  Major  Hardware  Groupings 

1.1.1  Functional  Description 

1.1.2  Milestones 

1.1.3  Status 

1.2  Software  Requirements 

1.2.1  Functional  Description 

1.2.2  Milestones 

1.2.3  Status 

1.3  Maintenance  and  Repair  Data 

1.3.1  Airborne  Equipment 

1.3. 1.1  Suggested  Source 

1.3. 1.2  Test  Equipment 

1.3.1. 3  Tools 

1.3. 1.4  Spares  -  LRU  and  Part  Level 

1.3.2  Special  Test  Equipment 

1.3.3  Common  Test  Equipment 

1.3.4  Automatic  Data  Processing  Equipment 

Facility  Requirements 

2.1  Equipment  Area 

2.1.1  Layout 

2.1.2  Scale 

2.2  Physical  Details 

2.2.1  Size 

2.2.2  Weight 

2.2.3  Environmental 
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2.2.3. 1 

2.2. 3.2 

Noise  Levels 
RF  Hazards 

2.2.4 

Tempest 

2. 2. 4.1 

2. 2. 4. 2 

2.2.4. 3 

Regulations 

Equipment 

Installation 

2.2.5 

Power 

2. 2. 5.1 

2. 2. 5. 2 

2. 2. 5. 3 

28  Vdc 

Requirements 

Connectors 

2.2.6 

2.2.7 

2.2.8 
2.2.9 

Heat 

Air 

Lighting 

Hydraulics 

2.2.10  Pneumatics 

2.2.11  Laser  Light 

2.2.12  Cryogenics 

2.3  Transfer  Information 

2.3.1  Block  Diagram 

2.3.2  Equipment  Identification 

2. 3. 2.1  Numbers 


3.  Budget  Information 

3. 1  Common  Test  Equipment  -  Stock  Listed  Only 

3.2  Peculiar  Equipment 

3. 3  Computer  Peripherals 

3.4  Administrative  Equipment 

3.5  Non  Stock  Listed  Equipment 

3.6  Fiscal  Year  Data 

3. 7  Back  Dp  Data  Required 

3.7.1  Forms  and  Letters 

3. 7. 1.1  Status 

4.  Critical  Events 

4.1  Status  of  Critical  Events 

5.  Responsible  Individuals 


5.1  System  Engineer 

5.2  Supervisor 
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Below  Is  a  list  of  support  software  programs  used  on  the  F-15  TEWS. 


SEQUENTIAL  ORDER  OF  PLACEMENT  AND  FUNCTION 


VERSION:  V-EX-001-A 


This  program  Initializes  the  TEWS  TT2520 
assembler  on  the  datacraft  slash  four 
computer. 


TLIBRARY 


Thi3  program  provides  all  of  the  functions 
required  to  utilize  and  maintain  the  F15 
TEWS  library. 


VERSION:  V-EX-001 


This  program  initiates  then  completes  Link/Load 
function. 


This  program  updates  the  org  and  instruction 
addresses  of  a  preassembled  and  linked 
TI-2510  program. 


TPUNCH 


This  program  punches  tape  with  the  contents 
of  pseudomemory . 


TVERIFY 


This  program  compares  the  contents  of  pseudo¬ 
memory  with  a  punched  tape . 


This  program  clears  the  test  central  interface 
and  clock  and  starts  the  TI  computer. 
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The  amount  of  flight  test  is  a  function  of  the  kind  of  change.  Most  of  the 
V  and  V  testing  is  done  on  a  simulator  in  the  lab. 
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PREDICTIVE  SOFTWARE  COST  fitODEL 


SOFTWARE  PACKAGE  CHARACTERISTICS  -  TRAINING  REQUIREMENTS  DATE:  31  JAN  80 
PROGRAMMER  TRAINING. 

GENERIC  TRAINING  REQUIREMENTS  FOR  REPROGRAMMABLE  EW  SYSTEMS 


1.  Introduction 

a.  EW  System  Theory  of  Operation 

b.  Integrated  Support  Station  (ISS)  System  Theory  of  Operation 

2 .  Airborne  EW  System 

a.  EW  System  Programming  Language (s) 

b.  EW  System  Software  Theory:  In-depth  study  of  the  System  Operation 
Flight  Program 

c.  EW  System  Operator's  Course:  Required  for  large  power  management  systems 
when  the  ISS  contains  a  system  hot-mockup 

d.  EW  System  Maintenance  (Hardware):  To  include  trouble-shooting/repair 
of  the  reprogrammable  EW  system  and  all  interfaces 

3.  Integrated  Support  Station  (ISS) 

a.  ISS  Programming  Language (s) 

b.  ISS  Software  Theory:  Familiarization  with  system  unique  support  software 
used  on  the  ISS,  to  include  de-bug  programs  and  simulators.  In-depth 
study  of  compilers,  assemblers,  operating  systems,  and  utilities  not 
normally  required,  but  may  be  needed  for  particular  systems. 

c.  ISS  Operator's  Course 

d.  ISS  Maintenance  (hardware):  To  include  total  ISS  system  trouble-shooting/ 
repair. 

4.  Automatic  Test  Equipment  (ATE)  (Organization,  Intermediate,  Depot) 

a.  ATE  Programming 

b.  ATE  Operator's  Course 

I 

c.  ATE  Theory  of  Operation 

d.  Test  Software  Theory  of  Operation 

5.  General  Training  Requirements  for  Reprogrammable  EW  System  Engineers  and 

Technicians.  Designed  to  bring  engineers  and  technicians  with  no  (or  little) 

previous  EW/ECM/ECCM  experience  to  an  acceptably  productive  level. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET _  _  DATE:  31  JAN  80 


a.  Principles  of  Radar:  Analysis  of  radar  principles  designed  to 
familiarize  personnel  with  radar  principles,  modulation  techniques 
and  radar  pulse  signatures,  which  will  improve  efficiency  in  the 
capabilities  of  engineers  to  recognize  the  techniques  required  to 
counter  these  threats. 

b.  Principles  of  EW/ECM/ECCM:  Designed  to  provide  personnel  with  a 
general  overview  of  the  concepts  and  principles  of  electronic  warfare 
and  its  functional  parameters. 

c.  Jammer  Techniques:  A  detailed  study  of  the  jammer  and  its  role  in 
the  EW  scenario,  specifically  its  interface  into  a  power  management 
system. 

d.  Radar  Warning  Receivers:  A  detailed  study  of  radar  warning  receivers, 
their  functional  role  and  interface  with  power  management  systems. 

e.  Threat  Radar  Updatas  (Periodic):  Designed  to  provide  EW  engineers  with 
a  periodic  review  of  existing  and  projected  threat  radars  and  their 
signatures. 

f.  Software  Configuration  Control/Mamgement :  Designed  to  educate  personnel 
in  the  support,  control  and  documentation  of  software  within  the  EW 
Management  Division. 

g.  Software  Validation  and  Verification  (V&V) :  To  acquaint  personnel  with 
the  computer  program  (software)  V&V  process  and  its  relationship  to  the 
computer  program  life  cycle. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


HISTORICAL  DATA  SOURCES 


DATE:  31  JAN  80 


Data  Base 


Location 


Contact  Person 


Phone  Number 


General  Contents 


Data  Quality 


Electronic  Warfare  Systems 
WR-ALC/MMRR,  Robins  AFB,  Georgia 
Bobby  McDonald 
(912)  926-2204/5780 

The  ALR-46  and  its  derivatives  have  been  in  the  field 
5  to  6  years.  Data  is  available  in  the  project  log  files. 
The  ALR-62  and  ALQ-131  are  newly  fielded. 

Manhours  to  task  level.  Requires  manual  search  and 
summarization. 


PREDICTIVE  SOFTWARE  COST  MODEL 

RECOMMENDATIONS  RE  SOFTWARE  SUPPORT  COST  PREDICTING _ DATE:  31  JAN  80 

RESPONDENT:  Bobby  McDonald 


•  Need  to  know  system  type,  complexity,  accuracy  requirements.  From  this 
you  can  make  a  manpower  estimate. 

•  The  AISF  estimate  depends  on  the  S/W  tools,  diagnostic  tools  and  degree 
of  automation  involved. 

•  Need  to  know  the  S/W  structure.  In  particular  are  operational  parameters 
spread  throughout  the  program  or  tabled? 

•  How  maintainable  is  the  EW  software? 
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APPENDIX  H 


ATE/SAALC  DETAILED  DATA 
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PREDICTIVE  SOFTWARE  COST  MODEL 
FIELD  EVALUATION  REPORT 


GENERAL  SOFTWARE  PACKAGE  DESCRIPTION 


15  Feb.  '80 


WEAPON  SYSTEM:  ATE 


SOFTWARE  PACKAGE:  Not  Applicable 

(N/A) 

PERSONNEL  CONTACTED: 

Roy  Wimpee,  MMMMD 

Bob  Clay,  MMIRAB 

Jim  Lincoln,  MMIR 

Harry  Cogbum,  MMEC 

Bob  Smallwood,  MMIR 

Rod  Staggs,  MMIC 

Cecil  Smith,  MMIMP 

John  Ferrell,  MMIMP 

Jim  Sides,  MATT 

SOFTWARE  PACKAGE  CHARACTERISTICS: 

SIZE:  N/A 

LANGUAGE: 

APPLICATION: 

COMPLEXITY: 

YEAR  DEVELOPED: 

DEVELOPER: 

COMMENTS 

HOST  (AIRBORNE)  COMPUTER  CHARACTERISTICS: 
MANUFACTURER:  N/A 

MODEL  NUMBER/DESIGNATOR: 

WORD  SIZE: 

MEMORY  SIZE: 

MEMORY  FILL: 


WEAPON  SYSTEM  USE: 

NUM8ER  OF  USERS:  N/A 

LOCATIONS  OF  USERS: 

FREQUENCY  OF  USE: 


INTER  VIEWER  (SI:  R.  B.  Waina,  G.  L.  Foreman 
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PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  PERSONNEL 


DATE: 


.15  Feb.  1980 


OFFICE  SYMBOL: 


TOTAL  ASSIGNED  PERSONNEL  (NUMBER  &  TYPE): 

MMECA  has  24  personnel  overseeing  avionics  and  ATE.  MMIR  and  MMIM  have  a 
requirement  (FY'80)  of  28  (breakout  by  system  on  page  H-3) 


TOTAL  PACKAGES  MAINTAINED  (NUMBER  &  TYPE): 

Of  about  400-500  ATE  systems,  20-30  are  most  active  with  respect  to  software. 


FY'80  manpower  requirement  by  system  is  as  follows: 


System 


Manpower  Req.t.  (MMIM  and  MMIR) 


A-7D  0 . 46 

A  10A  1.34 

B-52  2.02 

FB-111  0.60 

C-5  0.57 

C  130  0.55 

C-135  0.45 

C-141  0.46 

E-3A  2.08 

E-4  0.70 

F-4  1.26 

F-5  3.45 

F-15  0.93 

F-16  2.78 

F-101  0.45 

F-105  0.45 

F-106  0.53 

F-lll  0.91 

T-38  0.45 

T-43  0.45 

T-45  0.45 

AGM-28  0.45 

AGM-65  C.00 

AGM-69A  0.80 

LGM-30  0.45 

Avionics*  2.06 

Communications*  0.41 
Missile  Systems*  1.42 
Simulators  0.08 

Miscellaneous  0. 90 

TOTAL  27.91 

♦Multiple  Weapon  System  Applications 


PLUM. 
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DESCRIPTION  OF  WORK  PACKAGE  DISTRIBUTION,  INCLUDING  RESPONSIBILITIES  AND  DEGREE  OF 
SPECIALIZATION  OF  AF/CS/CONTR  PERSONNEL 


30%  of  the  MMEC  work  is  done  by  contractors,  55%  is  done  by  MATT,  and 
15%  by  MMEC, 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


15  Feb. 1980 


NOTE:  Much  UUT  (unit-under -test)  software  is  controlled  by  WR  A.LC.  WR-ALC/MMECT 
has  29  personnel  overseeing  approximately  2000  CPINs.  MMECT  determines  the 
need  for  software  changes,  develops  the  functional  specifications  and  does 
V&V.  MZxx  does  the  actual  coding. 


PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  COST  ACCOUNTING  SYSTEM 

Very  diverse. 


WR-ALC/MMECT  has  several  ways  of  recording  manhours.  Log  books,  Work 
Authorizations  to  Item  Managers,  and  Project  Folders  (Form  138).  No  data 
are  available  in  machine-processable  format. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES 


DATE: 


15  Feb. 


1980 


SUPPORT  PHILOSOPHY: 

Changes  to  ATE  software  programs  and/or  documentation  can  be  grouped  into  two 
classifications,  each  requiring  different  processing  and  review  procedures  dependii 
on  the  impact  of  the  changes.  Changes  may  be  required  for  different  reasons, 
such  as  problems  identified  in  the  field,  testing  conducted  at  a  support  facility, 
new  mission  requirements,  and  engineering  modifications.  CPCI  changes  are 
classified  I AW  Appendix  XIV  of  MIL-STD-483  (USAF)  as  Class  I  (design)  and  Class  II 
(discrepancy). 

a.  Class  I  Software  Changes.  Those  changes  not  affecting  system  equipment 
may  originate  as  a  problem  or  as  an  engineering  or  mission  requirement.  Fach 
change  must  be  examined  to  determine  any  impact  upon  equipment  or  other  computer 
programs.  When  the  change  affects  equipment  or  exceeds  the  existing  organic 
capability,  AFR  57-4  procedures  apply. 

b.  Class  II  software  changes.  Those  changes  not  affecting  system  equipment 
result  from  a  discrepancy  and  are  not  design  or  equipment  Problems,  but  may  be 
changes  to  the  CPCI  or  associated  documentation, 

CHANGE  CONTROL  METHODS:  ~  "  ~~  ~~  ™ 


FORMAL  OR  INFORMAL:  Semi-Formal 


CHANGE  REVIEW  PROCESS.  See  pages  H-8  and  H-9 . 


CONFIGURATION  IDENTIFICATION  METHODS:  -  CPIN 
Off-line  S/W  controlled  by  Version  Descr.  Document  n/s. 

CONFIGURATION  CHANGE  CONTROL  METHODS: 

See  pages  H-8  and  H-9. 

CONFIGURATION  STATUS  ACCOUNTING  METHODS: 

AFCR  system  at  OC-ALC  -  Controlled  by  T)'s 

SOFTWARE  LIBRARY  CONTROL  PROCEDURES: 

Just  being  established 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


15  Feb •  1980 


Configuration  Control  Board  (CCB) .  After  PMRT  the  SA-ALC/MM  CCB  Is  the  configura¬ 
tion  change  control  authority.  It  has  the  responsibility  for  all  changes  to  the 
ATE  system  and  Its  configuration  items.  Its  members  should  be  representatives 
of  all  Involved  agencies  and  system  functional  areas  such  as  configuration 
management,  engineering,  programming,  system  analysis,  test  procurement, 
financial  control,  training,  and  logistics  support.  The  board  will  assure  that 
all  system  impacts  of  CPCI  changes  including  those  that  affect  equipment  or 
other  computer  programs  have  been  evaluated,  changes  to  system  documentation 
have  been  identified  and  the  resources  have  been  identified  to  implement  the 
change . 

Computer  Program  Configuration  Sub-Board  (CPCSB).  The  CPCSB  functions  as  a 
subordinate  element  of  the  CCB  and  will  be  designated  for  CPCI  change  processing. 
CPCI  here  refers  to  all  computer  programs,  whether  the  program  is  identified  with 
a  TO  number  or  with  a  Computer  Program  Identification  Number  (CPIN) .  For  computer 
program  changes  AFLC  Form  75,  CPCSB  Item  Record,  will  be  used.  If  hardware  is 
affected  as  well,  the  Form  75  will  be  used  as  an  attachment  to  AFLC  Form  48,  CCB 
Item  Record. 

a.  The  ATE  CPCSB  will  review  and  approve  all  CPCI  I  changes  that  do  not  affect 
system  equipment,  as  follows: 

(1)  Verify  class  of  program  change  involved. 

(2)  Perform  system/equipment  Impact  evaluation. 

(3)  Recommend  action  on  change. 

(4)  Forward  action  copy  to  the  CCB  when  the  change  involves  hardware. 

^5)  CPIN  will  be  used  as  the  modification  number. 

b.  The  CPCSB  will  review  and  approve  all  Class  II  changes.  When  appropriate, 
considering  the  complexity  of  the  system,  the  board  may  act  upon  Class  II  changes 
or  handle  these  changes  by  means  of  a  screening  function. 

c.  ATE  Computer  Program  (CP)  change  requirements  (Class  I  or  Class  II)  resulting 
from  or  causing  system. equipment  modifications  will  be  documented  on  AFLC  Form  75, 
processed  through  the  CPCSB  and  appended  to  the  AFLC  Form  48  (Class  IV  modification) 
or  AFSC/AFLC  Form  44  (Class  V  modification).  Total  CP  costs  will  be  identified 

in  block  12. f  of  the  AFLC  Form  48  for  Class  IV  modifications  and  block  20  of 
the  AFLC/AFSC  Form  44  for  Class  V  modifications.  The  budget  project  column 
on  these  forms  will,  in  all  cases,  be  annotated  with  the  appropriate  fund  cite, 
as  an  example,  EEIC  583.  These  forms  will  be  processed  through  the  CCB  according 
to  standard  procedures. 

d.  ATE  CP  only  changes  will  be  processed  as  organic  change  proposals  (OCP)  when 
accomplished  organically.  CP  only  changes  will  be  processed  as  ECPs  when 
accomplished  contractually.  All  CP  only  changes  will  be  documented  on  AFLC 

Form  75,  CPCSB  Item  Record,  and  processed  through  the  ATE  CPCSB  for  final  approval 
if  costs  are  within  allocated  funds.  Class  IV/V  modification  numbers  will  not 
be  assigned  to  CP  only  changes,  and  these  changes  will  be  excluded  fro  m the 
C079  system.  The  ATE  CPCSB  is  designated  as  the  final  approval  authority  for 
CP  only  changes  which  can  be  Implemented  within  allocated  resources,  and  in 
the  opinion  of  the  CpCSB,  do  not  require  CCB  approval. 
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PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  _  _ DATE.  15  Feb'  1980 


Specific  Division/Pranch  Responsibil ities ,  The  major  functional  responsibilities 
of  the  various  divisions/branches  concerning  software  configuration  are  described 
below  I AW  AFLCR  23-43. 

a.  MMI  will  exercise  ALC  surveillance  of  ATE  software  support  activities  and 
assure  coordination  with  all  agencies  involved  in  hardware,  software,  and  data 
modif ications/changes  of  associated  ATE  systems. 

b.  MMIM  will  analyze  planning  and  programming  documents  and  data  to  assure 
adequate  logistics  coverage.  Also  provide  managers  to  administer,  coordinate, 
and  control  the  management  of  ATE  software. 

c.  NMIR  has  responsibility  for  full  range  engineering  and  technical  Integration 
of  ATE  equipment  and  software  to  assure  design  performance  and  compatibility, 

and  that  all  ATE  CP  deficiency  reports  are  processed  and  controlled. 

d.  MME  will  provide  engineering  management  and  develop  engineering  design 
changes  for  ATE  ECS  programs.  Plan  and  program  for  the  capability  to  organically 
support  system  software. 

e.  KfoEC  nil  maintain  a  computer  program  distribution  program  to  assure  that 
material  is  issued  and  that  all  computer  programs  are  properly  numbered. 

f.  MMEC  will  identify  minimum  essential  weapon  system  computer  resources 
documentation  requirements  for  operational  support.  Conduct  or  participate  in 
verification  and  validation  of  assigned  ECS  programs.  Evaluate  and  define  the 
cause  of  software  deficiencies  related  to  ATE.  Determine  and  recommend  changes 
required  to  correct  those  deficiencies.  Maintain  files  and  issue  computer 
programs  and  documents t icr .  Evaluate  contractor-prepared  ECPs  for  computer 
programs  and  documentation  and  apply  cost  effectiveness  criteria.  It  is  also 
the  final  engineering  approval  authority  for  ECS  integral  to  the  ATE  system, 
processes  AFIC  Form  925,  CPIN  request,  to  obtain  CPINs  from  OC-ALC/MMFDUD,  and 
reproduces  computer  programs  for  distribution. 

g.  MMED  will  assemble  and  initiate  reproduction  of  manuals  by  the  Government 
Frinting  Office  (GPC) . 
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PREDICTIVE  SOFTWARE  COST  MODEL 


MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES  (Cont) _ DATE: 


STRUCTURED  DESIGN?  -  DESCRIBE 

NO 

STRUCTURED  PROGRAMMING?  -  DESCRIBE  1 

NO 

CODING  Gt  JELINES: 

NONE  -  Function  of  available  documentation 

CHANGE  ENTRY  METHODS:  1) 

A  \ 

Function  of  System  - 

C.ET  Key-in 

Punchcard  »-  punchtape 
resident  compiler  on  ATE 

SCHEDULE: 

Formal,  established  by  MIPS 

REPORTING: 

MIPS 

COMMENTS: 
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MAINTENANCE  AGENCY  -  POLICIES  &  PROCEDURES  ICont) _ DATE:  jg  Feb.  1980 

DOCUMENTATION: 

Applicable  documents  are  listed  on  pages  H-12  and  H-13. 

REQUIREMENTS: 


DESIGN: 


USER: 


PROGRAM  PROBLEM  REPORTING  SYSTEM: 

MIPS 


COMMENTS: 


PREDICTIVE  SOFTWARE  COST  MODEL 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET 


DATE: 


15  Feb.  1980 


MIL-STD-480  Configuration  Control,  Engineering  Changes,  Deviations 

and  Waiver 

MIL-STD-482  Configuration  Status  Accounting,  Data  Elements  and  Related  Test 

Features. 

MTL-STD-483  Configuration  Management  Practices  for  Systems,  Equipment 

and  Computer  Programs 

MIL-STD-1521  Technical  Reviews  and  Audits  for  Systems,  Equipment  and 
Computer  Programs 

MM0I  66-29  Configuration  Control  Board  Class  IV/V  Mods 

Material  Improvement  Projects 


MMOI  66-39 


PREDICTIVE  SOFTWARE  COST  MODEL 
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PERSONNEL  DESCRIPTION _ _ _ DATE:  15  Feb.  19? 0 

DESCRIPTION  OF  SKILL  LEVEL  AND  TYPE  (AF/CS/CONT)  OF  PERSONNEL  MAINTAINING  THIS  PACKAGE 

The  basic  skill  Is  the  GS-855/11  or  /12  electronic  engineer  (embedded  computer 
systems) . 


PREDICTIVE  SOFTWARE  COST  MODEL 


PREDICTIVE  SOFTWARE  COST  MODEL 


CONTINUATION  SHEET  TRAINING  REQUIREMENTS  -  MATT  DATE:  15  Feb-  1980 


COURSE 

LENGTH 

1. 

MCS-48 

System  Workshop 

40 

2. 

Interfacing 

Microprocessors 

24 

3. 

NOVA  Assembly 

Language  Programming 

80 

4. 

PDP-11  Assembly 

Language 

40 

5. 

Introduction  to 

Minicomputers 

40 

6. 

RTM  Operating  System 

Course  #133  and  #135 

80 

7. 

Bendix  Model  320 

Programming 

80 

8. 

AAI  5565  Applications 
and  Programming 

120 

9. 

Gen  Rad  Corp . 

ATE  Programming 

40 

10. 

Gen  Rad  Corp 

Simulation  Command  Language 

40 

11. 

Gen  Rad  Atlas  Translator 

40 

12. 

Hewlett-Packard 

HP9845  Programming  Course 

40 

13. 

Assertive  Management 

24 

14. 

Introduction  to  Microcomputers 
(Includes  SDK-85  Kit) 

32 
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PREDICTIVE  SOFTWARE  COST  MODEL 


HISTORICAL  DATA  SOURCES 


TE.  15  Feb.  198^ 


Possible  sources  on  ATE  software  support  data  at  SA-ALC  include  AFLC  Form  75 ’s 
and  minutes  of  the  CFCSB  meetings.  Initial  contact  would  be  Hoy  Vimpee,  ME'MMP . 

Possible  data  sources  at  WR-ALC/MMECT  are  discussed  on  page  P-6.  Primary  contact 
would  be  Don  Purvis . 
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